W3C home > Mailing lists > Public > www-forms@w3.org > July 2002

Re: XForms Schema Attached

From: Roland Merrick <roland_merrick@uk.ibm.com>
Date: Wed, 24 Jul 2002 15:25:41 +0100
To: Jérôme Nègre <jerome.negre@e-xmlmedia.fr>
Cc: "Micah Dubinko" <MDubinko@cardiff.com>, www-forms@w3.org
Message-ID: <OF323498F8.15E0B24F-ON80256C00.004DC597@portsmouth.uk.ibm.com>

Greetings, I think I have answered some of these in the respose to Martin
Plechsmid but here goes:

Regards, Roland

                      Jérôme Nègre                                                                                    
                      <jerome.negre@e-x        To:       "Micah Dubinko" <MDubinko@cardiff.com>, <www-forms@w3.org>   
                      mlmedia.fr>              cc:                                                                    
                      Sent by:                 Subject:  Re: XForms Schema Attached                                   
                      24/07/2002 13:29                                                                                


Glad to have some news from the Working Group!

This schema resolves several issues, but the following points are unclear

1) In <model>, shouldn't it be <xsd:group ref="xforms:actionGroup"/>
of <xsd:element ref="xforms:action"/>?

2) In <submission>, may-be that providing a default value for @method would
be useful.

3) Why use @ref in <bind> instead of @nodeset? It would be much more
consistent IMHO.
<ram>Yes, it should use nodeset on the bind element.</ram>

4) Everything is now in lowercase, except @minOccurs and @maxOccurs of
<bind>, is it on purpose?

5) I think there's a missing minOccurs="0" in the xsd:sequence of <label>,
<hint>, <help> and <alert>.

6) @id of <choices> and <item> should have an explicit use="optional" to be
more consistent.

7) Does incremental="true" means the use of a spinner or equivalent? If the
answer is yes, I'm not sure it's very relevant on <secret>.
 <ram>Allows author control over whether xforms-value-changing events
should be dispatched. Default for secret is false.</ram>

8) I'm not sure that the new name <select1> is better than the old
<selectOne>. Same issue with <select> and <selectMany>.

9) <selectMany>, er no, <select> has now @selection, I hope a suggestion of
rendering for a graphical browser will be available.
<ram>selection attribute is to spficy whether the enumerated alternatives
are "open" or "closed" The appearance attribute replaces selectUI and
allows rendering hints to be specified.</ram>

10) what's the use of bindFirstAttributes on <trigger>?
<ram>The trigger can now be bound to a model item such that the relevant
property can by reflected by the UI element trigger.</ram>

11) where is <repeat> gone, and what's the use of all those @repeat-*?
<ram>xforms:repeat should be there, new attributes are to allow for
integration of repeat processing with a host language.</ram>

12) In <switch>, @id could be optional.

13) In <switch>, what's the use of @default? Shouldn't @selected in <case>
be used instead?
<ram>This is unchanged from the last call version, but your observation is
still a good one.</ram>

Received on Wednesday, 24 July 2002 10:26:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:06 UTC