- From: Tom Keane <tkeane@home.com>
- Date: Tue, 5 Feb 2002 19:29:21 -0800
- To: <www-forms-editor@w3.org>
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 UTC