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