Print

Print


> I had somewhere the same problem, i.e. the (painful :-) dilemma:
> 
> a)	either fine control of the number of occurrences (obtained via 
> <sequence>);
> b)	or unconstrained order (obtained via <choice maxOccurs="unbounded">).
> 
> Maybe we should suggest W3C (for the XSD 1.1) the "natural" extension, 

Or even more elegant: generalising a bit the <all> construct, like:

<all>
	<element name="e(p)" minOccurs="n(p)" maxOccurs="m(p)">... </element>
 	...
 	<element name="e(q)" minOccurs="n(q)" maxOccurs="m(q)">... </element>
</all>

where n(i) >= 0 and m(i) >= n(i).

Feasable ?

Dan

> something like:
> 
> <choice minOccurs="x" maxOccurs="y">
> 	<element name="e(p)" minOccurs="n(p)" maxOccurs="m(p)">... </element>
> 	...
> 	<element name="e(q)" minOccurs="n(q)" maxOccurs="m(q)">... </element>
> </choice>
> 
> where the elements are allowed in any order, but WITH a constrained number of
> occurrences.
> 
> In this case, x and y are imposed (i.e. they could disappear ?):
> 
> x = sum (n(i), i = p..q)
> y = sum (m(j), j = p.. q) 
> 
> 
> What do you think ?
> 
> Dan
> 
> -----------------------------------------------------------------------
> Dan Matei, director
> CIMEC - Institutul de Memorie Culturala [Institute for Cultural Memory]
> Piata Presei Libere nr. 1, CP 33-90
> 013701 Bucuresti [Bucharest], Romania
> tel. (+40-21) 317 90 72; fax (+40-21) 317 90 64
> www.cimec.ro
> 
> 
> -----Original Message-----
> From: Joe Altimus <[log in to unmask]>
> To: [log in to unmask]
> Date: Fri, 8 Aug 2008 14:53:00 -0700
> Subject: Re: [MODS] schema use of xsd:sequence to define children of the 
> cartographics element
> 
> > OK, I think I get it. There is no good reason for rigidly ordering these
> > elements, we've just run into a limitation of the XML Schema standard.
> > 
> > On Fri, Aug 1, 2008 at 6:55 AM, Ray Denenberg, Library of Congress <
> > [log in to unmask]> wrote:
> > 
> > > <cartographics> is defined as xsd:sequence because <scale> and
> > >  <projection>
> > > are not repeatable, but <coordinates>  is repeatable.
> > >
> > > <all> requires that each element occur zero or one time and would not
> allow
> > > multiple <coordinates> elements.
> > >
> > > <choice maxOccurs="unbounded"> (which MODS uses in cases without such
> > > constraints)  would not constrain <scale> and <projection> to maximum one
> > > occurence.
> > >
> > > (Contrast this for example with <subject> ........
> > >
> > > <choice maxOccurs="unbounded">
> > > <element name="topic"/>
> > > <element name="geographic"/>
> > > <element name="temporal"/>
> > > <element name="titleInfo"/>
> > >
> > > etc.
> > >
> > > </choice>
> > >
> > > etc.
> > >
> > > .....any of these subject categories may occur any number of times,
> > > including zero, and the whole set may occur in any order.)
> > >
> > >
> > > ----- Original Message -----
> > > From: "Joe Altimus" <[log in to unmask]>
> > > To: <[log in to unmask]>
> > > Sent: Thursday, July 31, 2008 5:30 PM
> > > Subject: [MODS] schema use of xsd:sequence to define children of the
> > > cartographics element
> > >
> > >
> > > I notice that the MODS schema uses xsd:sequence to define the children
> > > of the cartographics element:
> > >
> > >        <xsd:sequence>
> > >               <xsd:element name="scale" minOccurs="0" type="xsd:string"/>
> > >               <xsd:element name="projection" minOccurs="0"
> > > type="xsd:string"/>
> > >               <xsd:element name="coordinates" minOccurs="0"
> > > maxOccurs="unbounded" type="xsd:string"/>
> > >        </xsd:sequence>
> > >
> > > However, an example of <cartographics> in the MODS User Guidelines
> > > does not conform to the schema:
> > >
> > > <subject>
> > >  <cartographics>
> > >    <coordinates>E 72--E 148/N 13--N 18</coordinates>
> > >    <scale>1:22,000,000</scale>
> > >    <projection>Conic proj</projection>
> > >  </cartographics>
> > > </subject>
> > >
> > > so I wonder if the example is wrong or the Schema (xsd:all instead of
> > > xsd:sequence)? Is there a strong reason why the children should occur
> > > in a rigid order in this case?
> > >
> > > Joe Altimus
> > > Arizona State University Libraries
> > >