W3C home > Mailing lists > Public > www-forms@w3.org > October 2001

RE: Strange construction in XForms schema

From: Josef Dietl <josef@mozquito.com>
Date: Mon, 8 Oct 2001 15:59:13 +0200
Message-ID: <D0F1529EE943B3449F755CA1A40887465263B3@winserver.windomain.mozquito.com>
To: Jérôme Nègre <jerome.negre@ecl2000.ec-lyon.fr>, <www-forms@w3.org>
> So, why not change the xsd:all to a simple xsd:sequence ? 
> What's the real
> benefit of using xsd:all here?

re-use and ordering. On re-use: we have so far had several significant
changes to what is now "commonUIChildren". Integrating that into every
individual content model is not much fun and error-prone. It is also
much easier to create new UI elements that way.

On ordering: by using sequence, designers MUST stick with the ordering
as given. As the ordering information is not meaningful, it will be
fairly hard for people to learn the correct ordering. So far, we can do
everything with simple "all".

Finally, the specific task of select[One|Many|...] requires additional
child elements, namely choices and items. This is where we are
inevitably hosed, because we don't know in advance how many of those
there are going to be. More precisely: we know that there are going to
be more than one, which is incompatible with the "all" mechanism, it is
compatible only with "sequence".

The only expression compatible both with Eric's expected implementation
of XML Schema and our requirements is to require authors to write (I'm
ommitting the attributes, it's for illustration only anyway) for the
minimal case:

	<caption>Captions are always required</caption>
			<item>This is the first item</item>
			<item>This is the second item</item>

in order to enable more complicated cases like:

	<caption>Captions are always required</caption>
			<item>This is the first shirt</item>
			<item>This is the second shirt</item>
		<!-- different choices-groups are separated, e.g. by a
bar -->
			<item>This is the first sweater</item>
			<item>This is the second sweater</item>

IF you all here on the list agree that such a "container" element is
acceptable, please let us know and we can reconsider. So far, the
Working Group thinks that it's by far too user-repelling to demand such
additional markup. (Note that we would still have to figure a name for
the thing, my question refers solely to the binary decision "shall we or
shall we not have such an element" - assuming of course that there
actually is such a choice and I haven't missed the corresponding
constraint in the Schema spec.)

So: what do you think, everybody?

Received on Monday, 8 October 2001 09:59:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:50 GMT