Date:         Thu, 6 Nov 2003 09:30:12 -0500
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         "Houghton,Andrew" <[log in to unmask]>
Subject:      Re: Reusing MODS elements
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

> From: Rebecca S. Guenther [mailto:[log in to unmask]]
> Subject: [MODS] Reusing MODS elements
>
> There may be some technicalities with XML schema that makes
> this true that
> I don't know. But I thought that the real issue is whether you can
> identify a metadata element with a URI. If you can, then you
> could use it
> in another schema. We have been involved in an agreement (CORES) to
> provide URIs for our metadata elements. This would apply to
> MARC elements
>
> On Wed, 5 Nov 2003, Robin Wendler wrote:
>
> > Could I beg for a little Schema for Dummies advice?
> >
> > Did the MODS schema authors consider making more of
> > the MODS subelements global elements, and "ref-ing" them
> > within the larger elements such as originInfo?

The CORES effort is slightly different, it allows you to use URI's
for linking mechanisms like XLink or resources in RDF.  The URI's
that CORES standardizes can also be used for namespaces and/or
qualified names.  What I believe that Robin is talking about is
not URI's but how the actual MODS XML schema is specified.

In particular it's the persistent use of nested elements in the
XML schema.  When I was working with LC on the MARC-XML schema
this was one of the reasons why I requested that all elements
be made global.  It allow others to reuse or redefine them in
their schemas, rather than inventing new metadata schemas and
elements that will eventually need to be cross walked for
interoperability.

The difference between the XML schema constructs look like this:

<!-- MODS "nested" style -->

<xsd:element name="e1">
  <xsd:element name="e1.1">
    <xsd:element name="e1.1.1" type="xsd:string"/>
  </xsd:element>
</xsd:element>

<!-- Global style -->

<xsd:element name="e1" type="e1.t"/>

<xsd:complexType name="e1.t">
  <xsd:sequence>
    <xsd:element ref="e1.1"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:element name="e1.1" type="e1.1.t"/>

<xsd:complexType name="e1.1.t">
  <xsd:sequence>
    <xsd:element ref="e1.1.1"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:element name="e1.1.1" type="e1.1.1.t"/>

<xsd:simpleType name="e1.1.1.t">
  <xsd:restriction base="xsd:string"/>
</xsd:simpleType>

The "global" style is more verbose, leading to larger schemas,
however it also allows elements to be reused and redefined by
other schemas easier than the "nested" style.  For example, if
I wanted to redefine the "nested" element e1.1.1 to be the type
"xsd:anyURI" instead of "xsd:string", then I would be forced
to redefine the entire element structure from e1 all the way
down to e1.1.1.  This isn't a good situation since if the
orginal schema is modified to include new elements or attributes
under element e1 then I would need to modify my redefinition to
include those elements or attributes.  In the "global" style I
can merely redefine the simple type e1.1.1.t.  In addition, in
the "nested" schema, I cannot directly use element e1.1.1 in
another schema based upon the "nested" schema because the element
isn't global.  In the "global" style I can reuse elements e1,
e1.1 and e1.1.1 in another schema based upon the "global" schema.

Andy.