[tei-council] <date>, <distance>, and <measure>
Syd Bauman
Syd_Bauman at Brown.edu
Sat Jan 20 10:55:36 EST 2007
> If you believe the attList specification allows what you need, then
> I should implement it. I'm willing to have a try, if its needed.
I certainly think the <attList> specification allows this:
<elementSpec ident="duck">
<attList org="choice">
<attList org="group">
<attDef ident="A1" usage="req"/>
<attDef ident="A2" usage="req"/>
</attList>
<attList org="group">
<attDef ident="B1" usage="req"/>
<attDef ident="B2" usage="req"/>
</attList>
</attList>
</elementSpec>
This states that a <duck> must have either both A1= and A2= or both
B1= and B2=, and can't have all four of them (or zero, one, or three
of them).
This could be expressed in RelaxNG as
<rng:element name="duck">
<rng:choice>
<rng:group>
<rng:attribute name="A1">
<rng:empty/>
</rng:attribute>
<rng:attribute name="A2">
<rng:empty/>
</rng:attribute>
</rng:group>
<rng:group>
<rng:attribute name="B1">
<rng:empty/>
</rng:attribute>
<rng:attribute name="B2">
<rng:empty/>
</rng:attribute>
</rng:group>
</rng:choice>
<rng:empty/>
</rng:element>
which in the compact syntax requires what always looks to me like an
extra layer of parenthesis, but makes sense when you think of the
outer parens as <rng:choice> and the inner parens as <rng:group>:
element duck {
(
( attribute A1 { empty }, attribute A2 { empty } )
|
( attribute B1 { empty }, attribute B2 { empty } )
),
empty
}
What I'm not certain of is whether we want to change the
implementation to do what the specification permits, or change the
specification so that you can't do this. I lean towards the former,
but it may be more effort than it's worth.
> On the other hand, restrictions like this are good candidates for
> Schematron, as you say.
True. And although there are some disadvantages with using Schematron
(speed problems jump to mind), it does have the advantage of
providing a check for those who use DTDs.
More information about the tei-council
mailing list