[
Lists Home |
Date Index |
Thread Index
]
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
|