W3C home > Mailing lists > Public > www-forms-editor@w3.org > February 2002

Re: GET should be encouraged, not deprecated, in XForms [was: Issue request for the TAG: XForms]

From: Tom Keane <tkeane@home.com>
Date: Tue, 5 Feb 2002 19:29:21 -0800
To: <www-forms-editor@w3.org>
Message-ID: <000a01c1aebe$7c2d3000$13df0844@sd.cox.net>
Perhaps instead of deprecating GET its use should be restricted.

If I understand the issues correctly, one of the main reasons GET was
deprecated due to complications in formatting arbitrary XML documents to fit
the syntax of GET. This is a valid concern, and requiring GET to support
posting arbitrarily complex XML documents has the potential to complicate
the XForms specification.

Boris (and others) have also raised valid scenarios where GET is useful or
even necessary.

I would propose the following restrictions on the use of GET as a submit
method in XForms:
1. Only the text content of the first level children of the model's root
node will be submitted. No attributes or sub-children will be included in
the submission.
2. Every first level child of the model's root node must have unique tag
names. If there are repeated tag names, only the first element is submitted
3. The tag names of the first level children must conform to the current
restrictions for field names in HTML forms.

The goal of the above restrictions is to limit the data that can be
submitted using GET to that which can easily be transformed into name-value
pairs.

Examples:
Each example assumes the form is using GET to submit data to
http://www.searchengine.com/search

Both of the instance models would result in the following URL:

http://www.searchengine.com/search?firstname=Elvis&lastname=Presley

Simple example:
<model>
  <firstname>Elvis</ firstname>
  <lastname>Presley</lastname>
</model>

More complex example:
<model>
  <firstname someAttribute="value"> Elvis </ firstname>
  <lastname> Presley </lastname>
  <lastname>Grbac</lastname>          <!-- Ignored, not first occurrence of
<lastname>  -->
  <jobs>                                            <!-- Ignored, has no
direct text content -->
    <job>Singer</job>
    <job>Quarterback</job>
  </jobs>
</model>

I suggest that this approach has several advantages:
1. Allows the valid use of GET in applications where it is the most
desirable choice with well-defined semantics.
2. Doesn't force the XForms spec to jump through hoops to overcome the
limitations of GET in the general case.
3. Removes ambiguity from the spec. User and implementers will have concrete
guidance on the level of support to expect and/or provide for forms using
GET as the submit method.

Cheers-
Tom Keane
tkeane@cardiff.com





> Subject: Re: GET should be encouraged, not deprecated, in XForms [was:
Issue request for the TAG: XForms]
> Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> I just wanted to say that while GET does have known issues, there are two
major advantages GET form submission results over
> POST submission results:
> 1) GET submission results can be bookmarked.  Granted, browsers could jump
through some hoops and "bookmark" POST form
> submission results by saving all the data that was posted.  This, however,
would be very inefficient for large POST submissions
> (which are currently already POST).  Furthermore, there is the implicit
agreement that POST submissions may change
> information on the server, while GET ones should not.  This distinction is
why POST results are not bookmarkable, since the
> operation that happens on the server may not be idempotent. Making all
forms use POST will remove this distinction.
> 2) GET form submission results can be directly linked to as needed. This
is much used in existing systems of various sorts from
>  eBay to Bugzilla.  This allows one to send a friend a url that will allow
him to retrieve the same information that one retrieved via
> the form.
>
> I feel that deprecating GET without providing a non-deprecated alternative
to achieve similar functionality is a bad idea.  I
> understand that GET is still supported, but the fact that it's deprecated
means it will be removed at some point (once XForms are
> widely used and compatibility with existing HTML is not an issue).
> Removing it without providing a way to achieve the same flexibility and
ease-of-use for the user seems like a poor course of action
> to me.
> Thanks for your time, Boris
Received on Tuesday, 5 February 2002 22:20:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:10 GMT