Print

Print


Well that settles it. Versioning the namespace identifiers definitely
helps for this use case and the proposal
(http://www.loc.gov/standards/premis-version.doc) that Ray created does
the trick.

-Chris

Evan Owens wrote:

>We expect to reference two or more different versions of a schema from a
>single instance document and all our systems are designed to support
>that.  The use case goes like this:  event metadata for an object is
>cumulated in blocks in a METS wrapper; each block reflects the version
>of the event metadata schema in use at that time the event was
>generated.  We might in the future migrate the embedded metadata to a
>later version, particularly if the version is not backward compatible
>but we aren't promising to do it instantly so we expect to have
>different versions in the same METS wrapper.  Another example might be
>technical MD; we wouldn't necessarily discard the earlier metadata if we
>created new metadata to a newer standard so there could well be two
>blocks using different versions of the same schema.
>
>Because of this, we strongly favor being absolutely clear about what
>version of a schema is being referenced at any given point.  All our own
>internal identifiers include version information.  Our sanity will
>suffer if we don't know exactly what is intended at all times.
>
>Evan
>
>==================================
>Evan Owens, Chief Technology Officer
>Portico  www.portico.org
>[log in to unmask]  (609) 258 8230
>228 Alexander Street, Princeton NJ 08550
>
>
>
>
>
>
>-----Original Message-----
>From: PREMIS Implementors Group Forum [mailto:[log in to unmask]] On Behalf Of
>Christopher Vicary
>Sent: Friday, July 08, 2005 3:49 PM
>To: [log in to unmask]
>Subject: Re: [PIG] namespaces and versions (fwd)
>
>Actually I was saying that keeping the same namespace identifer across
>versions is OK because parsers will identify any definition conflicts if
>the same namespace is imported more than once from different schema
>locations. It really depends on what we're trying to accomplish. I can't
>come up with a good reason to reference 2 or more different versions of
>a namespace from a single instance document or schema, so I would rather
>disallow it. Maintaining the same namespace across versions facilitates
>this. But if the goal is to reference different namespace versions from
>a single document, then I agree that versioning the namespace identifier
>is a better approach. If so, the METS people might want to take note
>since they keep the same namespace identifier across versions (versions
>only differ according schema location).
>
>Chris
>
>Ray Denenberg, Library of Congress wrote:
>
>
>
>>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
>
>
>>>----------------------------------------------------------------------
>>>---
>>>
>>>
>>>
>>>
>>
>>
>>
>
>--
>------------------------------------------------------------------------
>-
>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
-------------------------------------------------------------------------