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