Print

Print


The scenario I had in mind is represented by this sample schema:

............................................................................
...............
<xsd:schema

xmlns:mods1=http://www.loc.gov/mods1
xmlns:mods2="http://www.loc.gov/mods2"   ......>

<xsd:import namespace="http://www.loc.gov/mods1"
schemaLocation="mods1.xsd"/>
<xsd:import namespace="http://www.loc.gov/mods2"
schemaLocation="mods2.xsd"/>

<xsd:element name="root">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="mods1:titleInfo"/>
<xsd:element ref="mods2:titleInfo"/>
<xsd:element name="otherElement1"/>
<xsd:element name="otherElement2"/>
<xsd:element name="otherElement3"/>
<xsd:element name="etc"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

</xsd:schema>
.........................................................

In this case someone has constructed a (hypothetical) schema that mixes
elements from two mods versions (along with other elements), specifically,
titleInfo, where (hypothetically) the titleInfo definition has changed from
(hypothetical) version 1 to (hypothetical) version 2.

Does this help?

--Ray




> ---------- Forwarded message ----------
> Date: Wed, 29 Jun 2005 18:50:03 -0400
> From: Christopher Vicary <[log in to unmask]>
> Reply-To: PREMIS Implementors Group Forum <[log in to unmask]>
> To: [log in to unmask]
> Subject: Re: [PIG] namespaces and versions
>
> Sorry it's taken me so long to respond to this. I want to be sure I
> understand the scenario Ray is setting up. From what I gather from the
> final paragraph, there is a concern that a single schema may reference
> another namespace more than once with different schema locations
> attached to each reference. If we use METS as an example, there might be
> a namespace declaration in a schema's root element that takes the form:
>
> xmlns:METS="http://www.loc.gov/METS/"
>
> and a corresponding location:
>
> xsi:schemaLocation="http://www.loc.gov/METS/
> http://www.loc.gov/standards/mets/mets.xsd"
>
> Later in the same schema there might be a conflicting reference to the
> same namespace in an import statement:
>
> <xs:import namespace="http://www.loc.gov/METS/"
> schemaLocation="http://www.loc.gov/standards/mets/version13/mets.xsd"/>
>
> Notice that while the namespace identifiers are the same, the locations
> are not.
>
> I wasn't sure exactly how a validating parser would handle this, so I
> created a test document and validated it using XMLSpy. It looks like the
> XMLSchema designers (or perhaps XML parser developers) have already
> considered this situation, because the referencing schema was invalid.
> The validator recognized that there are conflicting definitions within
> the same namespace. It appears as though we don't have to worry about
> this specific situation.
>
> I took it a step further and created a schema (test1.xsd) that
> references the METS namespace at the location
> http://www.loc.gov/standards/mets/mets.xsd. It also references another
> schema, test2.xsd. test2.xsd also references the METS namespace, but at
> the location http://www.loc.gov/standards/mets/version13/mets.xsd. In
> this hierarchical scenario, test1.xsd is invalid, again due to the
> definition conflict. test2.xsd, which only sees one reference to the
> METS namespace, is valid. To me, this does not seem to be problematic.
>
> I admit that I may not completely understand the situation outlined by
> Ray, if so, can someone provide a concrete example of the problem?
> Another caveat, I only had time to test this using one tool, XMLSpy,
> other validating parsers may treat this situation differently.
>
> Chris Vicary
>
>
> Ray Denenberg, Library of Congress wrote:
>
> >I just got subscribed to this list so pardon me if I'm out of context.
> >
> >Different schemas need different namespaces unless you can guarantee that
> >any name occuring in both schemas will have a common definition. Thus if
you
> >move from one version to another, take MODS for example, and you change
the
> >definition of, say, titleInfo, then if you want to maintain the same
> >namespace, you need to change the name of element titleInfo.
> >
> >I can't recall the exact example but in one of the MODS revisions we
> >concluded that it was much more disruptive to change the element names
(e.g.
> >titleInfo --> newTitleInfo) than to change the namespace.
> >
> >A generic namespace with different locations doesn't get around this. You
> >cannot guarantee that sometime in the future some third schema won't
> >reference names from two different schemas with the same namespace.  When
> >that happens, if the reference an element that has different definitions
in
> >the two schemas, you'd be in trouble.
> >
> >--Ray
> >
> >
> >
>
> --
> -------------------------------------------------------------------------
> Christopher Vicary: (352)392-9020 ext. 323
> e-mail: [log in to unmask]
> fax:    (352)392-9185
> -------------------------------------------------------------------------
>     _/_/_/_/    _/_/_/  _/          _/_/
>    _/        _/        _/        _/    _/
>   _/_/_/    _/        _/        _/_/_/_/   F C L A
>  _/        _/        _/        _/    _/    5830 NW 39th Avenue
> _/          _/_/_/  _/_/_/_/  _/    _/     Gainesville, Fl 32606
> -------------------------------------------------------------------------
> F l o r i d a   C e n t e r   f o r   L i b r a r y   A u t o m a t i o n
> -------------------------------------------------------------------------
>