RE: Potential Last Call comment to be resent to www-forms-editor@ w3.org

Greetings Werner,

In response to your message at:
http://lists.w3.org/Archives/Public/www-forms/2002Jan/0155.html

>Should we really care about legacy?

Yes, but with careful balance.

Our charter and requirements document [1] impose upon us to work out a
solution that will "encourage users to make use of the new capabilities,
rather than lingering on existing form technologies." 

At the same time, we're very aware of the potential to "box ourselves in",
which we want to avoid. Here are some specific changes we've made to
accomplish both of these goals:

* We define a backwards-compatible method for GET forms that uses
urlencoding and UTF-8 handling of special characters. We do not "deprecate"
GET. The flat name-value pairs are taken from the XML in a one-way
conversion process.

* For richer data submission, we define an XML serialization. For
interoperability, we require implementations to support http, but give
examples of many other possibilities (for instance, a PUT form could write
to the filesystem). 

* We permit implementations to provide new serialization methods and
submission protocols

* We are clarifying that all instance data maps to a DOM Document, and
provide an accessor to that Document. Through this, countless "dynamic
XForms" possibilities are opened, and there's no need for "submit" to have
something useful.


>In my opinion the specification would have more value if it didn't refer to
the web directly, but only specified, in isolation, what is required if it
is used in a web context.

We have made great strides in this direction. Probably a far as is possible
under a Web Consortium. :-) We define the following submit methods, with a
normative binding to HTTP and suggestions on how mailto:, file: and others
would fit the same descriptions:

get
put (file: for example)
post (mailto: for example)
legacy encodings (post-urlencoded, etc.)

>I think the central part of the specification should only cover behaviour
and content.

Another change we've made is to describe the pieces of XForms as "modules".
For instance, instead of a chapter on "Form Controls", we now have a chapter
on "The Form Control Module". This seems like just an organizational change,
but it has a much bigger effect on how people will look at and think about
using XForms. For general XForms-on-the-Web, we define a specific profile
that needs to be met. But if someone wants only XForms behavior and content,
for example, we are showing the recipe for that too. (In fact, we've had
great interest from companies that claim an embedded XForms implementation
will be cheaper for them to produce than a custom-UI).

>Separate sections could explain how the data, which is to be submitted, is
serialised in the various contexts. Obvious contexts are plain HTTP, SOAP
over any protocol such as HTTP, SMTP, etc., and even IIOP.

This is in fact now a separate section (chapter) in the specification. And
we do include examples of http, https, mailto, and file schemes, as well as
providing an extensibility mechanism for anything else (SOAP, IIOP, BEEP,
whatever).

I hope this answers your question. Thanks!

.micah


[1] http://www.w3.org/TR/xhtml-forms-req

> Thierry Michel wrote:
>
> > Dear Werner Donné,
> >
> > During the Last Call comment period for XForms, you sent a message [1]
to
> > the XForms public mailing list that has been identified as a potential
Last
> > Call comment. If you intended this message as a formal Last Call
comment,
> > but accidentally sent it to www-forms@w3.org instead of
> > www-forms-editor@w3.org, please respond in the affirmative to this
message
> > within the next two weeks.
> >
> > Sincerely,
> > Thierry Michel for the Xforms WG.
> >
> > [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/0155.html
> >
> >
> >
>
>
> --
> Werner Donné  --  Re BVBA
> Engelbeekstraat 8
> B-3300 Tienen
> tel: (+32) 486 425803 e-mail: werner.donne@re.be
>

Received on Tuesday, 25 June 2002 20:34:22 UTC