Re: Proposal for Extensions to HTML4

On Fri, 5 Dec 2003 andyh@collegenet.com wrote:
>
> Contrary to popular opinion, I plan on using XForms on the Web, and I
> suspect that many others like me, who are business application
> developers, will embrace XForms because it satisfies their need to build
> applications for the Web.

Great! I know that there is definitely a market for XForms; my concern is
that there is an even larger set of people who are _not_ business
application developers and yet still need their toolset upgraded, for whom
XForms is simply not appropriate (due to its complexity and the way it
separates content and data, something which most developers don't
understand or want).


> The separation of presentation from content is such a fundamental piece
> of good application development that it should not be underestimated and
> is vitally important to be able to scale the engineering effort.

Completely agreed. My proposal addresses this (as does HTML4's forms).


> With XForms, the server components can concentrate on data and
> downstream business logic. It does not have to concern itself with
> presentation and various controls. If the UI needs to change to reflect
> a different order of fields, the server component does not have to be
> changed.

This is also the case for my proposal, with the added |data| attribute on
the form element.


> This proposal makes the assumption that XForms is hard for authors to
> understand, that it is hard to grasp XML and some new tags, and yet are
> able to easily comprehend ECMAScript, DOM and the additional elements and
> attributes in this "XForms Basic".

Indeed. This does appear to be the case. XPath requires authors to think
in multiple levels of abstraction -- ECMAScript and the DOM (which to most
people are the same thing) is imperative. XSchema is abstract -- an
attribute with the value "datetime", "file", "text" is simple and obvious.
Namespaces obfuscate -- XHTML, with everything in one namespace, is easy.
That is the feedback I am getting from authors ranging from your average
Joe to developers and administrators of sites like voidwars.com.

Separation of content and style is important, but most authors have enough
trouble just getting the hang of that without having to force separation
of logic and content, or logic and types, of content and data models, etc.


>> "... field may have no value, in which case they aren't "successful", do
>> not take part in submission"
>
> The concept of a null value is very important and does not mean "not
> relevant". If I am editing an address form, how do I remove the contents of
> a second address line when I move to a simpler address? So is the server
> component supposed to understand that the absence of an element means
> deletion? Which means the form and server are tightly coupled because the
> server has to know exactly what fields are painted so it can perform
> actions on elements it is not told about.

This is simply a matter of backwards compatibility with HTML4. Since these
are the same forms as those already in use on millions of sites, the
semantics of things as simple as empty text fields cannot be changed.


>> Help attribute: "However, there is some doubt that this is actually a
>> useful feature."
>
> Excuse me, of couse help is important when developing applications.

I didn't say help wasn't useful, I said the help _attribute_ wasn't
useful. How do you expect it to be used? I've never understood how XForms'
|help| was supposed to be discovered by users. You can't rely on the F1
key (that's for UA help), you can't rely on context menus (unless every
site has help, the user would never know when to look for help). So how
would this attribute be used, in practice?


>> Repeat
> And this is supposed to be easier than XForms!

Yes, I wish there was a way to make this simpler. However, I think the
examples demonstrate that it is simpler than the specification makes it
appear (the problem is that defining it for UAs shows implementation
details which authors need not know).

Maybe I should add an introduction section explaining how to use the
repetition model.


>> Seeding a form with initial values
> This does not address the concept of separation of presentation from data
> because there is a one-to-one link between data and form controls.

Quoting from the introduction:

| The following features of XForms have not been addressed:
|
|    * The separation of the instance data model, data typing, field
|      interdependencies, and submission information from the content
|      model and interface elements.

If an author wants separation of content from data, then he should use
XForms, as that is XForms' strength.


> There is no ability to load dynamic <option> data, other than via script.

Ooh, good call. I'll add that to my list of things to consider.


>> XML Submission
> Yes, the data may be submitted as XML, but it is not in a particularly easy
> structure to work with.

It's a name-value pair list with some metadata. Since there is no separate
content model, it makes no sense to apply a structure to it.

However, with a transform step on the server side, it would be simple to
convert to a different structure.


> The proposal is not very clear on nested repeats - an example would
> help, but it looks like the concept of a hierarchy is lost.

Yes, I need to add another example for nested repeats.

The concept of hierarchy is expected to be represented in the names, as it
is today in hand-rolled repeating forms, as in:

   order1.name
   order1.quantity
   order2.name
   order2.quantity
   order2.comment1.text
   order2.comment2.text

That way the submission can remain compatible with the long-established
multipart/form-data, yet not lose the hierarchy. (Again, backwards
compatibility is critically important here.)


> Nor is this scheme useful for interfacing with web services, who dictate
> the XML vocabulary to use. Do you propose web services create another
> interface based on this <submission><field /></submission> scheme?

You don't submit a form to a Web service (how on earth would the UA know
how to render the returning envelope?). That kind of conversation (RPC,
SOAP) is executed from script (indeed the call represents or is
represented by a method call, typically).

Of course the REST model is considered better (indeed the TAG say that
"Designers of protocols SHOULD invest time in understanding the REST
model" [1]) and that is why the proposal includes new DOM interfaces to
enable such better designs than RPC and SOAP web services. Hooking a
little script into the submit event of a form that cancels the submission
and then does it manually using the aformentioned interface allows this
system to be used for all manner of REST-based Web services.

[1] http://www.w3.org/TR/webarch/#rest-model


>> "... output control can be populated ... The semantics of this practice
>> are somewhat dubious..."
> The concept of dynamic "boilerplate" text - text that has the appearance of
> static text but is generated dynamically is very fundamental. Again it goes
> to the separation of presentation and content.

Exactly. Boilerplate text is content, it has no business being in the data
model. This is something that is, as you say, fundamental.


> However, as output controls are not in the submission data you lose some
> round-tripping, which means the outputs to be preloaded should be in
> their own form with a separate source.

I'm not sure I understand what you mean here.

Thank you for your input!
-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 7 December 2003 18:56:51 UTC