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

["Michael D. Thomas" <mdthomas AT mindspring.com>]

> 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.

It's important to note that:

- XForms is quite a bit more than this one particular optional feature
of posting XML. 
- XForms doesn't always post XML. The XForms user may choose to send
data as name-value pairs or XML. I would be surprised to see a lot of
XForms web designers posting as XML unless there is a compelling reason
to do so on the server-side for a particular application. In a world
where the existing modules take name-value lists as input and people
have adopted that as a way to build such modules, the reason would have
to be intrinsic to XML or driven by server-side reason -- e.g., the
desire to reuse code across a web app and web services. (I personally
would not recommend reuse starting at the HTTP interface, but that
doesn't mean that others won't find such an approach effective.)

For those interested in how validation works with the various XML schema
languages, read the specs and tutorials. You'll get a better
understanding than you'll get from the context of an old way vs. new
debate, esp. when the debate isn't about a prime use case for schema
validation. Here are some of the better known ones:

http://www.w3.org/XML/Schema
http://www.relaxng.org/
http://www.schematron.com/
http://examplotron.org/0/3/
http://www.w3.org/TR/REC-xml#sec-prolog-dtd

Here are some articles comparing schemas:

http://www.xml.com/pub/a/2001/12/12/schemacompare.html
http://www.cobase.cs.ucla.edu/tech-docs/dongwon/ucla-200008.html

W3C facets, esp. the regular expression facets, are especially, um,
interesting.

For those interested in the general name-value pairs vs. XML debate,
check out the SOAP vs. REST debate. In the web services world, SOAP is
entrenched so a lot of the rhetoric works in reverse. However, the web
services input problem is much harder than the rather trivial HTML form
input problem, so the debate is technically different.

A couple of general responses:

- It's possible to apply a declarative approach to most validation
problems. I'm including strong typing as part of what I'm calling
"declarative approach," as well as regular expressions. Imperative
approaches are a lot more error prone to develop. Good imperative
approaches end up looking like declarative approaches, anyway. However,
declarative languages can suffer from performance problems. Also, you
are always guaranteed that an imperative approach will get the job done.

- I'd love to see how higher level objects can be constructed out of
name-value pairs in a generalized matter -- i.e.., namespace conflicts
can't be known and resolved at object definition time -- without
additional delimitation beyond = and &.

Per the original question "are we going to see a lot more posted XML
from traditional web clients?" I wouldn't put money on it, but I've been
wrong before. Both XForms and the MS ActiveX approach give you a way to
post XML from a traditional web browser. I can see some upside that may
compel some to post XML as HTML form input, but the question isn't up to
me. For it to be adopted a lot of people have to see a great deal of
upside. I see an analogy between the propeller vs. the jet engine. The
jet engine had a lot of upside, but it took a long time for the industry
to adopt. The incumbent technology has advantage. The challenger
technology has to be much, much better.

> > 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
> ---