Print

Print


Actually, XML schema language can express constraints like that (a name
authority must have only name variants with the same type attribute),
but the technique is aesthetically...dubious.  In English, you give each
descriptor an attribute with a fixed value that defines its equivalence
class (e.g. titles and name+title combinations might be variants of each
other, likewise geographic and hierarchicalGeographic, so they're in the
same class).  Then use keys and keyrefs to enforce the constraint that
descriptors in different equivalence classes can't appear in the same
MADS record.  Schema fragment:

<xs:complexType name="madsType">
...
    <xs:key name="eqclass-key">
        <xs:selector xpath="mads:authority/*"/>
        <xs:field xpath="@eqclass"/>
        <xs:field xpath="@type"/>
    </xs:key>
    <xs:keyref name="same-eqclass" refer="mads:eqclass-key">
        <xs:selector xpath="mads:variant/*"/>
        <xs:field xpath="@eqclass"/>
        <xs:field xpath="@type"/>
    </xs:keyref>
</xs:complexType>

<xs:complexType name="titleType">
...
    <xs:attribute name="eqclass" fixed="titles"/>
...
</xs:complexType>

<xs:complexType name="nameTitleType">
...
    <xs:attribute name="eqclass" fixed="titles"/>
...
</xs:complexType>

<xs:complexType name="titleType">
...
    <xs:attribute name="eqclass" fixed="names"/>
...
</xs:complexType>

etc.

>>> [log in to unmask] 12/17/04 7:18 PM >>>

<snip>

Not only does this make logical sense, it also allows one to much more
finely-control validation.  A person element thus cannot have an
authorized name that is a corporate name, and an authorized name that
is a person cannot have a variant that is a corporate name, or -- much
worse -- a title.