Internetworkers: http://www.ibiblio.org/internetworkers/

[Steven Champeon <schampeo AT hesketh.com>]

on Sat, Nov 15, 2003 at 11:43:18AM -0500, Michael D. Thomas wrote:
> > This turns out to be exactly what this potential customer did, and of
> > course we don't support editing the XML in this case. I'm trying to
> > figure out what we need to do in order to support XML on web pages
> > outside of non-browser-based SOAP clients.
> 
> As Calvin suggested, XForms is the standard to watch.
> 
> http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html#Submiss
> ionMethods
> 
> You may see more XML coming in HTTP POST bodies b/c of XForms, or you
> may not. With urlencoded, a browser posts a list of name-value pairs.
> That's workable -- has been for years.

In fact, that's all you need, and has been for years. I'm all for XML -
I use it myself. But I'm unimpressed with the hype around XForms so far.

> But with XForms (and the MS
> ActiveX approach described earlier), a form can post the input data as
> XML, which has a number of advantages:

...all of them unnecessary.
 
> - XML is a richer way of representing data. XML represents data as a
> tree, which is much more flexible and structurally descriptive than a
> name-value pair list.

Unless the forms themselves are more complex than name/value or
name/value,value,value pairs, you do not need any more complex format
to store the data.

> - XML has declarative validation languages, such as W3C Schema Language
> and RelaxNG. Declarative languages are the way to do validation.
> Imperative languages suck for validation. 

Most validation of posted data is one of several forms:

 - binary (is it present or absent?)
 - relational (if X is present, is Y present?)
 - length (is it long enough? is it the right size?)
 - substring (does it begin/end/contain the string XYZ?)
 - does it meet certain formatting standards (is it an email address/phone
   number/credit card number/ISBN/zip code/whatever?)

Beyond simple questions like "is it long enough" or "does it have exactly
16 digits and begin with a '4'" or "is it absent or present", you always
have to write or reuse custom validation code - XSchema doesn't help you
there, because it has no way of specifying the higher-level validation
(true email address validation is very difficult, credit cards and ISBNs
and other numbers have complex formulae for checking their validity, etc.)
Even though XML Schema 2 (Datatypes) allows you to specify certain things
like length, format, etc. but that doesn't really help you much.

> - A lot of work is being done on APIs that bind objects to XML -- e.g.,
> Castor and JAXB.

At lot of work has already been done on APIs that bind POSTed form data
to any object imaginable.

> - Web services is driving server-side developers towards receiving XML
> instead of name-value pairs. By posting XML from web pages, web apps
> have a more normalized architecture with fewer moving parts. On the
> server side, you handle XML input. You write no code for handling
> name-value pairs.

As it stands, you write little code for handling name/value pairs - that
code has been written for ten years or more, in many cases. 
 
> But people are pretty used to dealing with the old way of doing things.
> We'll see.

I'd put it differently. People are pretty used to things working and in
familiar and powerful ways, and are loath to adopt new technologies that
may require them to learn five to ten new standards that do not help
them do anything more than they can do today.

Don't get me wrong - Schema and RELAX NG are far more powerful than SGML
DTDs, when it comes to allowing document type architects to specify the
values a given attribute may contain, and I'm looking forward to more
exciting developments. But to say that using XML to post form data is a
great leap forward is, IMHO, specious at this point. 

-- 
hesketh.com/inc. v: (919) 834-2552 f: (919) 834-2554 w: http://hesketh.com
Book publishing is second only to furniture delivery in slowness. -b. schneier