Re: Update of WebFormsA spec

Hi John,

> Link:
> http://www.w3.org/MarkUp/Forms/specs/XForms1.2/modules/streamlined/index-all.html

It's a great piece of work, but it doesn't feel like an on-ramp, I'm
sorry to say. :) It's actually pretty complicated!

Would it not be better to focus very specfically on XForms usage in
(X)HTML to begin with? At the very least that would allow us to drop
the namespace prefixes for most of the attributes. It would also allow
you to remove a number of examples that describe what will happen in
'some other language', leaving the examples for HTML intact.

(Myself, I'd prefer to see us take this approach even further, and
come up with the definitive XForms+XHTML onramp, rather than getting
hung up on WebForms. But that's another discussion.)


> Please note that the WebFormsA spec has been updated in a number of ways
> described below.  The document is nearly ready for first public working
> draft, so we should be thinking in terms of getting a resolution to make
> this publication soon, since it need not have all technical content
> completed before FPWD.
>
> 1) Name changed from Forms-A to WebFormsA.  This removes the offending dash
> and restores the emphasis of this specification on our working group mission
> statement and key deliverable of our charter.

I'm even more convinced than ever that this is the wrong way to go,
but will leave that to one side for this email, and instead comment on
the draft as is.

So one thing, is that there remain some references to the namespace
'fa', which I believe should be changed to 'wfa'.


>  It will clearly communicate
> to the *full* web community that we are fully committed to specifications
> that cover forms on the web.

I think you mean "*In my view* it will clearly communicate..." :)

With respect, you keep asserting this point as if it's so self-evident
that everyone must agree. But I can only say again that the approach
you are proposing does *not* follow inevitably from the charter.

For a start, our charter looks at creating forms in the context of
HTML and XHTML. There is nothing there about creating a generic
attribute-based syntax that could work in any language.

So if we want to 'talk to the web community' -- something that is a
little late in coming, but no less welcome for that -- why not focus
on (X)HTML+XForms? The spec seems to me to be more complicated than
necessary, in part because it's trying to be more generic than we need
to be at this time.

An example of this approach is RDFa; it was always conceived as a
generic way to add attributes to any mark-up--style language, but the
first specification that we produced was RDFa+XHTML. This made it much
more manageable, and has also helped with adoption.

Anyway...again, putting aside whether this is the right way to pursue
this project, I have some comments on the spec itself, based on a
quick scan through. I haven't had a chance to dive in deeply yet, I'm
afraid, and will try to do so over the next couple of days.



In section 2 on Form Containment, you have:

  The generated <xf:model> element is required as it is used by the
XForms processor
  as the target of model events. The generated <xf:model> element has
no id attribute.

I don't think this really follows, since without an id attribute it is
not possible to register for events on this generated xf:model. I
don't of course mean that the model is not "required...by the XForms
processor". All I'm saying is that the reason the model is needed is
not that the model is "the target of model events".


In section 3 on Default Data Instance, you have:

  If a form also contains an explicitly declared <xf:model> element, then any
  <xf:instance> elements in the form that are not children of the
<xf:model> element
  must be ignored by implementations conformant to this specification.
An author who
  adds <xf:model> element to a form must therefore place any
preexisting <xf:instance>
  elements within it.

The first problem with that is that it requires quite a lot of
processing; you have to process the entire document before you know
whether to ignore any xf:instance elements or not.

But second, this kind of 'if this, then ignore that' is the kind of
thing that simplification was aimed at avoiding. Would it not be
better to start from the situation that authors might have orphaned
instances, and then try to come up with a reasonable 'meaning', rather
than to simply ignore them.

So, if we took that approach, we might just say that any instance that
has no model parent belongs to the default model. This default model
might be a global one, or the default model created by a form element.


You then have:

  If a form contains an <xf:model> element, then the first child
<xf:instance> element
  is the default data instance of the form unless <xf:instance>
element bears the default
  attribute set to a boolean false value. In this case, the form has
no declared default data
  instance.

I can see what you are trying to do, to allow authors to use
lazy-authoring even when instances are declared. But my initial
reaction is that this doesn't sit well with normal XForms behaviour.
But I'll look into it further before making too definitive a
statement. :)


In the examples further down, I think this is confusing:

  <form xmlns:my="http://example.org" form="my:form" ... >
     ...
  </form>

since the value of @form seems to create a form *and* create some data.


I've made comments on sections 4 and 7, below.


In section 5, I think we need to come up with something that meets the
needs of the JavaScript community. As things stand, the emphasis on
XPath is going to cause people to run a mile, regardless of what you
call the specification. ;)

At the moment we have things like this:

  <input type="text" name="payment" calculate="
      if(
        principal > 0 and interest > 0,
        principal * rate div (1.0 - power(1.0 + rate, -duration*12)),
        0
      )
    "
  />

It would be very straightforward to allow authors to choose whether
their expression language should be XPath or JavaScript (or indeed
Ruby or Python). Note that this would still be 'declarative' -- XPath
does not have the monopoly on being declarative. :)

I'd like to see a way to do this both on an attribute-by-attribute
basis, and on a global basis. One way to do the attribute-by-attribute
level might be to allow the use of XPointer to override whatever the
default expression language is:

  <input type="text" name="payment" calculate="#xpath(/a/b + /c)" />

  <input type="text" name="payment" calculate="#javascript(b + c)" />

A global default language could be set using some attribute, like this:

  <html expressionLang="xpath">
    ...
  </html>

It could be allowed to appear anywhere in a document:

  <form expressionLang="xpath">
    ...
  </form>

Perhaps the value of the attribute should be expressed in the way that
it is on the script element, today:

  <form expressionLang="text/javascript">
    ...
  </form>

I think there is an XPath equivalent, but I'm not sure what it is. Perhaps:

  <form expressionLang="text/xpath">
    ...
  </form>

Anyway, you get the idea, and my underlying point is that if you want
to address WebForms-related concerns, then it will need a lot more
than a compromise name.



> 2) The submission attributes have been written.  Note particularly the
> attributes source, target and prune.

Looks good.



> 3) A section on runtime operations on form controls has been added in order
> to contain the increase() and decrease() operations, but also to add a
> description of other operations, esp. the ability to get and set values of
> form controls.

In section 4.1, Getting and Setting the Value of a Form Control, you
suggest that:

  Each form control has an associated value property that contains the
current textual
  content being rendered by the form control.

The problem is that this property already exists in the DOM, which
will make it difficult for implementations to spot the data change and
propagate it through to the model. Can I suggest that rather than a
property:

  onClick="document.getElementById('X').value = 'Hello'"

we have a method:

  onClick="document.getElementById('X').setValue( 'Hello' )"

This will make it easy to spot when the model needs updating.


In 4.2, Setting the Focus to a Form Control, you have:

  All form controls are augmented with a method setfocus().

In the DOM, all form controls already possess the method focus(), so
do we need to replicate this?



> 4) The section on additional form control attributes has been filled out.
>  This has included label, hint, help and alert, but also others specific to
> select controls.

In section 7, Declarative Form Control Properties, you have alert,
help, and hint as strings. I think developers nowadays would be
wanting the ability to have embedded mark-up. This can be achieved
either by saying that @alert, @hint, etc., are IDREFs, used as
follows:

  <input name="fn" hint="fn-hint" />

  <span id="fn-hint">
    Please ensure that you enter your <em>first</em> name.
  </span>

Or it could be addressed by adding another attribute, so as to allow
for both references and literals:

  <input name="fn" hintid="fn-hint" />
  <input name="sn" hint="Please enter your surname" />

  <span id="fn-hint">
    Please ensure that you enter your <em>first</em> name.
  </span>

Note though, that <hint>, et. al., have important consequences for
accessibility, so it does feel like a backwards step to be providing
attribute versions. And since in HTML the @title attribute plays
largely the same role as @hint, I'm not sure it's worth having in its
attribute form.


Also in that section, @multiple could be an integer. I've never liked
the fact that XForms has <select> and <select1>, but not <select7>. :)
The alternatives don't necessarily need to be between one, and
'unlimited'.



> 5) A full glossary has been completed.

Great.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Wednesday, 5 November 2008 12:40:29 UTC