RE: [xml-dev] Schema help: choice of attributeGroups?

["Dare Obasanjo" <dareo@microsoft.com>]

choice of attributes (or attribute groups) is not allowed in W3C XML
Schema. It is an unfortunate oversight. 

-- 
PITHY WORDS OF WISDOM 
If the crooks are within pistol range, so are you.


This posting is provided "AS IS" with no warranties, and confers no
rights. 

 

> -----Original Message-----
> From: Louis_Barton [mailto:Louis_Barton@compuserve.com] 
> Sent: Wednesday, July 09, 2003 12:27 PM
> To: XML-DEV
> Subject: [xml-dev] Schema help: choice of attributeGroups?
> 
> Hi all,
> I am having difficulty expressing in Schema one aspect of our 
> data constraints. I hope someone will give me help with this, 
> or tell me definitively that it's impossible and I ought to 
> stop trying to find a solution.
> 
> We are migrating NeumesXML from DTD to Schema mainly so that 
> we can express more of the data constraints from our abstract 
> data model.
> Currently our XML processing is being done on the server 
> side, but we hope that eventually browsers will be able to do 
> client-side processing, thus reducing dependency on a 
> particular server. For this reason, I am inclined to stick to 
> Schema instead of using RELAX NG, Schematron, and so on, 
> which I expect are less likely to have browser support in the 
> near future. Also, we intend that our data-entry program will 
> dynamically build menus or forms from the Schema, so that 
> additions to the Schema will not entail rewriting the 
> data-entry program. We hope, furthermore, to maintain 
> information about constraints in just in one place -- the Schema
> -- and generate user-friendly documentation from that.
> 
> Here follows a description of the problem and my attempted solution.
> 
> Each NeumesXML file is a transcription of one chant from a 
> medieval manuscript. We have a roster of possible chant 
> _genres_, where each instance document is of exactly one 
> genre. (The possible genres include antiphona, versiculus, 
> responsorium, alleluia, and so on.) Our design calls for all 
> qualifications about meta-data, such as genre, to be 
> expressed entirely in tag Attributes.
> 
> We have an Attribute called  _type_ of _genre_, where the 
> possible values can be "A"=antiphona, "W"=versiculus, 
> "R"=responsorium, "Al"=alleluia, and so on. Some genres can 
> have an optional _subtype_, plus some genres can have an 
> optional numeric specifier (when several chants of this genre 
> could be sung on a particular occasion). Thus, there are four 
> possible Attribute configurations for genre, e.g.,
>         <genre type="A">
>         <genre type="A" n="5"/>
>         <genre type="A" subtype="AaB"/>
>         <genre type="A" n="3" subtype="AV"/> The difficulty 
> is that this pattern of optional subtypes and numbers is 
> peculiar to "A" (antiphona); for example, some genres cannot 
> have a numeric specifier.
> The possible values of _subtype_ depend on the particular 
> genre _type_, and some genres have no subtypes.
> 
> In trying to express these constraints in Schema, my idea has 
> been to delcare one attributeGroup for each genre. The 
> problem then simplifies to saying that the Attributes of the 
> _genre_ Element are defined by any one of several Attribute 
> groups. My reasoning from the W3C Schema Structures 
> specification is as follows.
> a) An Element declaration can have complexType in its content.
> b) complexType can include complexContent in its content.
> c) complexContent can include _choice_ in its content, which 
> can be followed by multiple attributeGroups.
> 
> A fragment of my attempted Schema follows.
> 
> <xsd:element name="genre">
>         <xsd:complexType>
>                 <xsd:complexContent>
>                         <xsd:choice>
>                                 <xsd:attributeGroup ref="antiphona"/>
>                                 <xsd:attributeGroup ref="versiculus"/>
>                                 <xsd:attributeGroup 
> ref="responsorium"/>
>                                 <xsd:attributeGroup ref="alleluia"/>
>                                 <!-- ... and so on ... -->
>                         </xsd:choice>
>                 </xsd:complexContent>
>         </xsd:complexType>
> </xsd:element>
> 
> <xsd:attributeGroup name="antiphona">
>         <xsd:attribute name="type" type="xsd:NMTOKEN" use="fixed"
> value="A"/>
>         <xsd:attribute name="n" type="NMTOKEN" use="optional">
>                 <xsd:simpleType>
>                         <xsd:restriction base="xsd:positiveInteger">
>                                 </xsd:maxInclusive value="15">
>                         </xsd:restriction>
>                 </xsd:simpleType>
>         </xsd:attribute>
>         <xsd:attribute name="subtype" type="xsd:NMTOKEN" 
> use="optional">
>                 <xsd:simpleType>
>                         <xsd:restriction base="xsd:NMTOKEN">
>                                 <xsd:enumeration value="AaB"/>
>                                 <xsd:enumeration value="AaE"/>
>                                 <xsd:enumeration value="AV"/>
>                                 <!-- ... and so on ... -->
>                         </xsd:restriction>
>                 </xsd:simpleType>
>         </xsd:attribute>
> </xsd:attributeGroup>
> 
> The above construction, however, does not seem to parse. I 
> hope to get advice on whether my solution-idea is basically 
> sound and, if so, whether I must use a particular parser for 
> this construction to be 'valid', or if I have made 
> syntactical mistakes. Or, if this approach simply won't work 
> in Schema, is there another work-around by which I can 
> express the constraints of our abstract model?
> 
> Many thanks,
> - Louis
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 
> 
>