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

Thank you for a clearly thought out well-written message free of
polemic and emotional reactions.

Much heat and little light has been generated here by the somewhat
confrontational  nature of preceding portions of this thread --that
helps no one make progress.

As someone else pointed out (perhaps Dave Cleary)--
the problem here may be mostly with the word "depricate" --rather than
the underlying intent--
and trying too hard to say whether someone will be arrested for using
GET is in my opinion not the right answer.

Most of the mechanisms that work on the WWW are used --and heavily
abused--
all one can do in creating a forward-looking architecture is to point
things in the right direction.

This is primarily the intent behind XForms.


Chris Haynes writes:
 > 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
 > 
 > 
 > 

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
              Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608
Fax:        1 (408) 927 3012
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
AIM:      TVRaman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Wednesday, 23 January 2002 22:41:03 UTC