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

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

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

- 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.
- 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. 
- A lot of work is being done on APIs that bind objects to XML -- e.g.,
Castor and JAXB.
- 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.

But people are pretty used to dealing with the old way of doing things.
We'll see.