RE: Strange construction in XForms schema (Ignore)

This message may be ignored.

How about:

<choiceOfChoices>
    <choices>
        <item/>
    </choices>
    ...
</choiceOfChoices>


No.. Actually, I don't really understand why you would need multiple choices
elements. Would all the items be loaded into the selectXXX or maybe each
choices has a relevant attribute? 

I personally think that any repeating structure should be contained and only
have siblings with the same fully qualified name. Although it makes the
vocab a bit more verbose, this makes parsing and XPathing so much easier.

- Ryan

P.S. If you say "choices" repeatedly it's no longer a word (like banana).




-----Original Message-----
From: Josef Dietl [mailto:josef@mozquito.com]
Sent: Monday, October 08, 2001 9:59 AM
To: Jérôme Nègre; www-forms@w3.org
Subject: RE: Strange construction in XForms schema


> 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:

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

in order to enable more complicated cases like:

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

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?

Josef

Received on Monday, 8 October 2001 11:11:55 UTC