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
-------------------------------------------------------------------------
|