RE: XForms Schema Attached

Hello.

After looking at the XForms Schema I'll present here my observations. At
first, my overall feeling is that, sadly, very few _substantial_ changes
have been made in the areas I am interested in. In particular, I noticed
that @bind on <submission>s and on form controls was introduced, multiple
<instance>s inside a model are allowed, @repeat-* attributes were
introduced, some new attributes for UI controls (and therefore of little
importance, from my view-point of a programmer) were introduced, several
elements and attributes were renamed - and that's all. Of course, not
everything is derivable from the schema, though the schema hints a lot.

 - The most important thing I was objecting against since the LastCall WD
was that the data, model and UI layers are not clearly separated, that they
are in fact mixed together. Unfortunately, I must say, that nothing has been
changed in this area. 
For instance: I agree that the newly introduced @bind is functionally
equivalent to @relevant,  @readonly etc. on UI controls (suggested by us as
a solution for the layer issues). But as <bind>s can reside in models only,
this forces us to put restrictions related only to the visual layer into the
model layer.
Another example: In the current status of XForms it is completely legal (and
therefore necessarily acceptable) e.g. to toggle a <switch> from an action
placed in a <bind> or <submission> inside a model. I.e. to directly modify
the visual layer from the model layer, though the dependence between the
layers should be in the opposite direction.

Perhaps I am blinded by my own idea of how forms should be split into
layers, and you have your own idea on your mind. Then, please, explain it to
me, because I don't see any. And I hope we all agree that having layered
forms would be advantageous for all parties - form authors, form maintainers
and authors of form processing engines.


My other remarks are incomparably less important than the objection above:

 - <bind> should have @nodeset instead of @ref.
 - <repeat> is missing.
 - <switch> is, in our opinion, misconceptional. This is the only UI element
that doesn't change its state automatically according to instance data (via
@ref), and can only be changed using <toggle> action as a response to an
event in the UI. @relevant (even when tied to the UI control via @bind) does
the same job in a more elegant way. If you decided to remove @class, I thing
<switch> and <toggle> belong to XForms neither.
 - For UI controls that are to display calculated values, one has to
introduce now an auxiliary model and put there the calculated values for the
purpose of displaying them. However, our experience shows that using
auxiliaries for such a purpose is TOO MUCH complicated - and XForms are to
simplify work of form authors, not complicate it. Using auxiliaries makes
even relatively simple forms almost unmanageable. I can suggest a solution -
to allow @value (like the one on <setValue>) as an alternative to @ref on
<output>, <label> and other elements of similar kind.

Don't understand me wrongly. I don't complain that my suggestions were not
accepted. I am disappointed that my _problems_ were not reflected (solved -
anyhow).

With my other remarks, I'll wait till more information on the current status
of XForms is available.

	Best regards,
				Martin Plechsmid.



> -----Puvodní zpráva-----
> Od: Micah Dubinko [mailto:MDubinko@cardiff.com]
> Odesláno: 23. cervence 2002 20:19
> Komu: 'www-forms@w3.org'
> Predmet: XForms Schema Attached
> 
> 
> XForms enthusiasts,
> 
> Attached to this message is a development snapshot of the 
> Schema for XForms.
> This document has no official status.
> 
> The XForms Working Group has agreed to post this to provide 
> feedback on our
> progress of resolving Last Call issues.
> 
> We welcome comments and bug-spotting here, though we are not accepting
> substantive changes for XForms 1.0 any longer.
> 
> Thanks!
> 
> .micah
> 
>

Received on Thursday, 25 July 2002 12:20:19 UTC