[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Schema help: choice of attributeGroups?

  • To: "Louis_Barton" <Louis_Barton@c...>,"XML-DEV" <xml-dev@l...>
  • Subject: RE: Schema help: choice of attributeGroups?
  • From: "Dare Obasanjo" <dareo@m...>
  • Date: Wed, 9 Jul 2003 13:05:43 -0700
  • Thread-index: AcNGUC70KypTdfA0SieL4E5qDTMpgwABSwrw
  • Thread-topic: Schema help: choice of attributeGroups?

xsd attribute choice
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@c...] 
> Sent: Wednesday, July 09, 2003 12:27 PM
> To: XML-DEV
> Subject:  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>
> 
> 
> 

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.