Print

Print


Hello,

    I take back what I said about adding elements to enforce type
checking.  There's a better, user-extensible way of doing it.  To make,
say,
    <identifier type="isbn">4872871030</identifier>
valid while
    <identifier type="isbn">872871030</identifier> <!--oops, missing
region prefix-->
is not, validate against the following schema...

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.loc.gov/mods/v3"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.loc.gov/mods/v3" elementFormDefault="qualified"
attributeFormDefault="unqualified">
        <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
        <xsd:import namespace="http://www.w3.org/1999/xlink"
schemaLocation="http://www.loc.gov/standards/mods/xlink.xsd"/>
        <xsd:include
schemaLocation="http://www.loc.gov/standards/mods/v3/mods-3-0.xsd"/>
        <xsd:complexType name="isbnIdentifier">
                <xsd:simpleContent>
                        <xsd:restriction base="identifierType">
                                <xsd:pattern value="[0-9]{9}[0-9X]"/>
                                <xsd:attribute name="type"
fixed="isbn"/>
                        </xsd:restriction>
                </xsd:simpleContent>
        </xsd:complexType>
</xsd:schema>

...and use xsi:type to explicitly set the datatype of <identifier>,
(assuming you've set
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"):
    <identifier type="isbn"
xsi:type="isbnIdentifier">4872871030</identifier>
    <identifier type="isbn"
xsi:type="isbnIdentifier">872871030</identifier> <!--no longer
schema-valid-->
Whether the type="isbn" attribute is redundant depends on how one is
using schemata.  If the file is checked for validity independent of
other processing, 'type' should be included if it was before.  If
subsequent processing is done to the post-validation, augmented
information set, explicit 'type' is optional if its value is declared
fixed as in the example schema above.

Benefits:
* The MODS schema proper is not modified in any way.
* Documents valid under the modified schema are still valid under MODS
if types are derived by restriction only.
* The user need not maintain and modify a local copy of the MODS schema
to enforce stricter typing.

Disadvantages:
* Another attribute to remember (xsi:type).
* At the moment the technique can be used for these elements with
simple content...
    <classification>
    dates
    <genre>
    <identifier>
    <note>
    <placeTerm>
    <recordContentSource>
    <targetAudience>
...but not with these ones...
    <form>
    <geographicCode>
    <languageTerm>
    <physicalLocation>
    <roleTerm>
...because the latter group currently have anonymous types in the MODS
schema.

--Andy

>>> [log in to unmask] 2004-01-22 15:22:27 >>>

On Jan 22, 2004, at 3:09 PM, Andrew E Switala wrote:

> What would be perfect would be to have authority/type attributes
that
> actually meant something to a schema processor. Or something
similar.

Yes; true.

While I've not tried it, I'm pretty sure RELAX NG would allow
attribute-value specific data-typing (I know it allows other
attribute-level validation).  Perhaps at some point we'll see the same
in XML Schema...

Bruce