Re: GET should be encouraged, not deprecated,in XForms

How's this for a line of reasoning?:

1)  XML is the 'new generation' method-of-preference for holding
structured data,

2) XForms is the 'tool' supporting the editing and validation of such
data,

3) Within the HTTP protocol there are (at least) two distinct needs
for structured data:

3A) The URI may need data additional to the simple single-dimensional
server/page path in order to fully identify the 'Resource'. The best
example I know is the request for a portion of a street map, where the
origin and scale are an integral part of the Resource I am Indicating.
This data is an integral part of the URI - it needs to be
bookmarkable, printable, mailable, etc. If XForms is to be *the*
chosen mechanism for editing data, and URIs are to be capable of
carrying client-edited data, then XForms must be capable of editing
data that becomes (is?) part of the URI.

3B) The second HTTP need is to submit data to be stored, processed,
etc. This is usually carried in a POST message.

As I work with servlets in an OO-way, I use a simple OO mental model.
The information carried in the URI line identifies the 'Object' (e.g.
the portion of a map) that I want to send a 'message' to. The data
carried in the MIME extensions below the HTTP headers in a PUT is the
'content of the message'.

4) It's not exactly an issue of GET vs. PUT. Its the fact that there
are two quite distinct sets of data, with different semantics, used in
different ways, and which HTTP tells us to put in different places,
which may both need to be transmittted at the same time.

5) It would be 'sad' (English understatement) if XForms were not able
to be used to manage both sets of data.

6) If we accept the need for structured data (edited by XForms) to
become part of the URI, we move to the interesting issue of how that
data is to be embedded in the URI.

7) Within the HTTP / URI RFCs there appears to be more than one way to
carry data. As well as carrying it after the '?' there is a
'parameter' mechanism permitting constructs such as
www.site.com/page;long:77;lat:83

I thing the 'interesting' question for some list (maybe not this one)
is :

    "How (if at all) could a set of XML-structured data be part of a
URI?"

All of the following (pre-character-encoding) seem possible and legal:

site.com/map;<origin><long>77</long><lat>83</lat></origin>

site.com/map;perspective:<origin><long>77</long><lat>83</lat></origin>

site.com/map?perspective=<origin><long>77</long><lat>83</lat></origin>

as well as the flattened non-XML:

site.com/map?long=77&lat=83

which is fine so long as the data is one-dimensional, but quickly
becomes ghastly to interface with  if the data structure has 'depth'
to it.

The reference

http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-08.txt

which Bjoern Hoehrmann kindly sent me earlier today shows that,
syntactically, there will soon be a way in which full (multilingual)
XML such as the above can be incorporated as part of a URI.

There are still a number of logical and practical gaps to fill, but
surely we should be, at the very least, working out how the data from
XForms implementations is going to be interfaced into the HTTP
submission process?

I can think of a number of 'creative' ways I could hack this myself
with a bit of client-side javascript and a co-operative servlet, but
if I can then so too can Microsoft, Mozilla, Opera, etc - and I'm sure
they'll all want to be creative in different ways ;-)

How is a standard to evolve in this area?

The full resolution of this perhaps belongs with other lists, but, as,
I assume, people are soon going to want to pilot XForms
implementations with these capabilities, we could have 'de facto'
approaches emerging before the issue has even been acknowledged by
other communities.

At the very least it seems right to 'agitate' here for the problem
(opportunity?) to be recognized and addressed.

Chris Haynes

Received on Wednesday, 23 January 2002 20:38:07 UTC