|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Schema help: choice of attributeGroups?
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








