I think maybe we're saying the same thing. I got into this discussion late,
Rebecca was telling me that premis was tentatively considering using a
single namespace across versions (even major versions) and I told here I
thought it was a bad idea. Seems you do to. Please see separately posted
message: (subj: versioning/namespacing/location). --Ray
From: "Christopher Vicary" <[log in to unmask]>
> Off the top of my head, I'm not sure that versioning namespaces as
> described below (using mods) presents any *new* challenges. Let's say
> that namespaces are required. When a schema imports elements from other
> schemas, you must include the external namespace prefix for those
> elements in instance documents. Since the namespace identifiers and
> their prefixes are unique, there is no problem here in determining which
> element definition to use. Again, I mocked up a test for this situation
> using XMLSpy and there was no problem because the validating parser
> required that namespace prefixes be used.
>
> Let's say for the sake of argument that there is a way avoid using
> namespace qualification. In this situation I believe there would be a
> problem, there would be no way to tell which definition of the element
> should be used. The important thing to remember, however, is that this
> would always a problem, regardless of whether the referenced namespaces
> are related versions. So the situation described below in which we have
> 2 namespaces, mods1 and mods2, with like-named elements being referenced
> from each namespace is no different from having 2 unrelated namespaces,
> say foo and bar, that contain like-named elements that are referenced
> from a 3rd shema (eg. foo:title and bar:title). Semantically, they
> present the same problem. That's probably one of the reasons namespaces
> are used in the first place.
>
> Now the situation described below is actually different from what was
> proposed for PREMIS (and what is used by METS). Below, each namespace
> identifier is unique, http://www.loc.gov/mods1 and
> http://www.loc.gov/mods2, and so are the schema locations. What we were
> proposing for PREMIS is to maintain the same namespace identifer, but
> version the schema locations. The possibility for confusion here seems
> greater, but I covered why I think even that situation is not a problem
> in my previous email.
>
> Again, I want to reiterate that the tests I created to prove the
> concepts were run using only XMLSpy which is my XML editor du jour (hey
> it's free and seems to work well). I have noticed cases where XMLSpy
> handles namespaces differently than say Xerces, but if anything XMLSpy
> seems to fall on the strict side of things. If I have some time, I may
> try out some other parsing tools.
>
> It might be nice to get another opinion on this topic, Jerry are you out
> there?
>
> -Chris
>
>
> Ray Denenberg, Library of Congress wrote:
>
> >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
>
>>-------------------------------------------------------------------------
> >>
> >>
> >>
> >
> >
> >
>
> --
> -------------------------------------------------------------------------
> 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
> -------------------------------------------------------------------------
|