Re: Expressing varying cardinalities of unordered elements in a complex-type

>   Out of curiousity, does anyone have any links to discussions as to why
> this sort of constraint wasn't included in the W3C XML Schema?  Or more
> specifically, why "all" doesn't allow for cardinality >1?

I can't seem to find it now but I'm sure I've read somewhere that the reason (or
at least one of the reasons) for this constraint is to reduce the complexity of
schema processors.

Cheers,
/Eddie

>
>
> Cheers,
> Mason
>
> -----Original Message-----
> From: Eddie Robertsson [mailto:eddie@allette.com.au]
> Sent: Monday, December 03, 2001 4:07 PM
> To: Mason Lee
> Cc: Jeni Tennison; xmlschema-dev@w3.org
> Subject: Re: Expressing varying cardinalities of unordered elements in a
> complex-type
>
> Hi Mason,
>
> >   Not being used to functional programming and finding XML Schema somewhat
> > elusive, I just have to ask again then, a slightly different question:
> >   How might I use XML Schema to define a complex-type of 1 Element_A, 1
> > Element_B, 0 or 1 Element_C, and any number of Element_D, all appearing in
> > any order?
> >   Thanks in advance.  I'm not sure why this seemingly simple situation
> > doesn't appear in any of my books.
>
> The answer to why it doesn't appear in any of your books is because you
> can't
> express these constraints with W3C XML Schema. As Jeni has shown you can
> play
> around with mixing the different groups to achieve some of the more simple
> interleave constraints and in many cases an unrestricted choice group is
> enough.
>
> <xs:choice minOccurs="0" maxOccures="unbounded">
>    ...element declarations...
> </xs:choice>
>
> To declare the content model you describe above you have to move to a
> different
> schema language. Both RELAX-NG and Schematron can express the content model
> you
> describe and my personal favourite is to use Schematron rules embedded in
> W3C
> XML Schema. See [1] for an example of how to use embedded Schematron rules.
>
> Cheers,
> /Eddie
>
> [1] http://lists.w3.org/Archives/Public/xmlschema-dev/2001Nov/0049.html
>
> >
> >   Regards,
> >   Mason
> >
> > -----Original Message-----
> > From: Jeni Tennison [mailto:jeni@jenitennison.com]
> > Sent: Saturday, December 01, 2001 5:39 AM
> > Subject: Re: Order of elements in a complex-type
> >
> > Hi Mason,
> >
> > > Hi all! I saw Erik Beijnoff's good answer to the above question in a
> > > recent thread. I wonder further, however, how could this complex
> > > type be defined such that the elements "TextBox" and "TextArea" may
> > > appear any number of times, but the element "Header" must appear
> > > only once, and while retaining the interesting characteristic that
> > > any of these three clild elements may appear in any order. Any
> > > ideas?
> >
> > Assuming that you don't care if the TextBox and TextArea elements are
> > intermingled, and there's no minimum number of occurrences of TextBox
> > and TextArea, you could use the following:
> >
> > <xs:complexType name="FormType">
> >   <xs:sequence>
> >     <xs:group ref="TextBoxOrTextArea" minOccurs="0"
> >               maxOccurs="unbounded" />
> >     <xs:element name="Header" type="HeaderType" />
> >     <xs:group ref="TextBoxOrTextArea" minOccurs="0"
> >               maxOccurs="unbounded" />
> >   </xs:sequence>
> > </xs:complexType>
> >
> > <xs:group name="TextBoxOrTextArea">
> >   <xs:choice>
> >     <xs:element name="TextBox" type="TextBoxType" />
> >     <xs:element name="TextArea" type="TextAreaType" />
> >   </xs:choice>
> > </xs:group>
> >
> > (Using a group so that you only have to declare TextBox and TextArea
> > once.)
> >
> > Cheers,
> >
> > Jeni
> >
> > ---
> > Jeni Tennison
> > http://www.jenitennison.com/

Received on Monday, 3 December 2001 21:59:16 UTC