RE: [xml-dev] XML schema - multiple import of module

["DUNN, Mark" <mark.dunn@oup.com>]

Thanks again Michael.

I think a customized version of the schema may be actually what I need
here. 

I need my <p> to be different in 'main.xsd', but <p> is part of the
model of a number of elements in the core 'struct.xsd' (e.g. elements
for list items, hierarchical 'blocks' of text (divs), etc.) These other
elements are also imported into main.xsd, but I want their <p> to have
the extended model. 

So I either need local declarations for all these elements (which
defeats the goal of modularization), or to import the schema and modify
it.

This works fine until I introduce the third schema, 'law.xsd', which has
its own definition of <p>.

Maybe the law.xsd schema needs to be rethought. 

My next thought is that this schema could be something of a
'placeholder', defining the element names in the target namespace, but
not defining their content, and not importing 'struct.xsd'. The
definition of the content of <law:extract> would be done instead by
redefining the 'law.xsd' schema in 'main.xsd', alongside the
redefinition of 'struct.xsd'. This would avoid the problem of defining
<p> twice (by importing struct.xsd into both law.xsd and main.xsd).

Is there a conceptual or practical problem with this?

Regards,

Mark


-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: 08 June 2009 11:10
To: DUNN, Mark; xml-dev@lists.xml.org
Subject: RE: [xml-dev] XML schema - multiple import of module


If the content model for the <p> element is different depending on the
context where it appears, then you should be using a local element
declaration for <p>. xs:redefine does something quite different: it
creates
a customized version of a schema. The effect of xs:redefine is global -
if
you redefine type T, it affects everywhere in your schema that T is
used.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay  

> -----Original Message-----
> From: DUNN, Mark [mailto:mark.dunn@oup.com] 
> Sent: 08 June 2009 10:52
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML schema - multiple import of module
> 
> Thanks Michael,
> 
> Thanks also to George, with essentially the same solution, 
> and to Lech for suggesting NVDL.
> 
> Having two schemas that import each other still seems kind of 
> circular, but better than my rickety chain of imports, and 
> XMLSpy allows it.
> 
> The reason for using xs:redefine was that I want a <p> in a 'main.xsd'
> document to be allowed to contain certain other elements 
> defined only in main.xsd itself. 
> 
> The bigger picture is that we have a 'core' set of structural 
> elements (paragraphs, titles, typographic elements, etc.) 
> included in various other DTDs (for legal documents, 
> chapter-based books, A-Z reference, etc.). I need the model 
> of <p> (from the core set) to be slightly different in each 
> of the including DTDs, and am looking for a way of expressing 
> this in XML Schema.
> 
> I chose the xs:redefine element because it corresponded to 
> the way the old DTD was defined.
> 
> Maybe I need to have a separate <p> element in the including 
> schemas, in a separate namespace from the core <p> element, 
> and extending its model.
> 
> Thanks again for all the suggestions!
> 
> Regards,
> 
> Mark
> 
> 
> 
> -----Original Message-----
> From: Michael Kay [mailto:mike@saxonica.com]
> Sent: 04 June 2009 18:32
> To: DUNN, Mark; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML schema - multiple import of module
> 
> Unfortunately the topic of schema composition is one where 
> the spec isn't all that prescriptive, and where in 
> consequence there are differences between implementations.
> 
> Having said that, I can't see why you have three schema 
> documents or why you are trying to use xs:redefine.
> 
> You should have two schema documents, one for each namespace, 
> and each should reference the other using an xsl:import. If 
> your chosen tool doesn't allow that, I can only suggest you 
> try a different tool.
> 
> Regards,
> 
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay  
> 
> > -----Original Message-----
> > From: DUNN, Mark [mailto:mark.dunn@oup.com]
> > Sent: 04 June 2009 17:35
> > To: xml-dev@lists.xml.org
> > Subject: [xml-dev] XML schema - multiple import of module
> > 
> > Hello,
> > 
> > I'm new to XML Schemas, and investigating conversion of a DTD to an 
> > XML Schema. I have a problem describing the Schema version of the 
> > following
> > structure:
> > 
> > <doc>
> >  <div>
> >   <title>Section 1</title>
> >   <p>Some text...</p>
> >   <p>
> >    <law:extraxt>
> >     <title>Title of Regulation</title>
> >     <p>Text of regulation</p>
> >    </law:extract>
> >   </p>
> >  </div>
> > </doc>
> > 
> > 
> > The problem is in the non-namespaced <title> and <p> elements 
> > occurring within the namespaced <law:extract> element. They are the 
> > same as the ones occurring outside this element, so I'd 
> like to define 
> > them only once.
> > 
> > My attempt at expressing this structure uses three .xsd files:
> > 
> > main.xsd:
> > 
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
> > xmlns="http://xsd.oup.com/ac-xsd/";
> > xmlns:law="http://xsd.oup.com/ac-law/";
> > targetNamespace="http://xsd.oup.com/ac-xsd/";
> > elementFormDefault="qualified">
> > 	<xs:redefine schemaLocation="struct.xsd">
> > 		<xs:group name="paragraph-content">
> > 			<xs:choice>
> > 				<xs:group ref="paragraph-content"/>
> > 				<xs:element ref="law:extract"/>
> > 			</xs:choice>
> > 		</xs:group>
> > 	</xs:redefine>
> > 	<xs:import namespace="http://xsd.oup.com/ac-law/";
> > schemaLocation="law.xsd"></xs:import>
> > 	...
> > </xs:schema>
> > 
> > law.xsd:
> > 
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
> > elementFormDefault="qualified"
> > targetNamespace="http://xsd.oup.com/ac-law/";
> > xmlns:law="http://xsd.oup.com/ac-law/";
> > xmlns:struct="http://xsd.oup.com/ac-xsd/";>
> > 	<xs:import schemaLocation="struct.xsd"
> > namespace="http://xsd.oup.com/ac-xsd/";></xs:import>
> > 	<xs:element name="extract">
> > 		<xs:complexType>
> > 			<xs:sequence>
> > 				<xs:element ref="struct:title"
> > minOccurs="0"/>
> > 				<xs:element ref="struct:p"
> > minOccurs="1"/>
> > 			</xs:sequence>
> > 		</xs:complexType>
> > 	</xs:element>
> > 	...
> > </xs:schema>
> > 
> > 
> > struct.xsd:
> > 
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
> > elementFormDefault="qualified" attributeFormDefault="unqualified"
> > targetNamespace="http://xsd.oup.com/ac-xsd/";
> > xmlns="http://xsd.oup.com/ac-xsd/";>
> > 	<xs:group name="general-inline">
> > 		<xs:choice>
> > 			<xs:element ref="b"/>
> > 			<xs:element ref="i"/>
> > 		</xs:choice>
> > 	</xs:group>
> > 	<xs:group name="paragraph-content">
> > 		<xs:choice>
> > 			<xs:group ref="general-inline"></xs:group>
> > 			<!-- ... [plus others] ... --->
> > 		</xs:choice>
> > 	</xs:group>
> > 	<xs:element name="p">
> > 		<xs:complexType mixed="true">
> > 			<xs:choice minOccurs="0" maxOccurs="unbounded">
> > 				<xs:group ref="paragraph-content"/>
> > 			</xs:choice>
> > 		</xs:complexType>
> > 	</xs:element>
> > 	...
> > </xs:schema>
> > 
> > 
> > When I try saving the schema files in XMLSpy 2009, I get an error 
> > saying that <title> is already declared, presumably because 
> the file 
> > struct.xsd has ben imported twice.
> > 
> > The W3C spec says that importing twice is legitimate, but 
> vendors are 
> > encouraged to raise it as an error. Fair enough - I don't like the 
> > circularity in my description.
> > 
> > But the structure itself seems reasonable, I just can't see 
> a way of 
> > expressing it in XML Schema.
> > 
> > Can anyone help?
> > 
> > 
> > Kind regards,
> > 
> > Mark Dunn
> > XML Data Engineer
> > Oxford University Press
> > 
> > Oxford University Press (UK) Disclaimer
> > 
> > This message is confidential. You should not copy it or 
> disclose its 
> > contents to anyone. You may use and apply the information for the 
> > intended purpose only. OUP does not accept legal responsibility for 
> > the contents of this message.
> > Any views or opinions presented are those of the author 
> only and not 
> > of OUP. If this email has come to you in error, please delete it, 
> > along with any attachments. Please note that OUP may intercept 
> > incoming and outgoing email communications.
> > 
> > ______________________________________________________________
> > _________
> > 
> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS to 
> > support XML implementation and development. To minimize spam in the 
> > archives, you must subscribe before posting.
> > 
> > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > subscribe: xml-dev-subscribe@lists.xml.org List archive: 
> > http://lists.xml.org/archives/xml-dev/
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > 
> 
> Oxford University Press (UK) Disclaimer
> 
> This message is confidential. You should not copy it or 
> disclose its contents to anyone. You may use and apply the 
> information for the intended purpose only. OUP does not 
> accept legal responsibility for the contents of this message. 
> Any views or opinions presented are those of the author only 
> and not of OUP. If this email has come to you in error, 
> please delete it, along with any attachments. Please note 
> that OUP may intercept incoming and outgoing email communications.
> 
> ______________________________________________________________
> _________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by 
> OASIS to support XML implementation and development. To 
> minimize spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org List archive: 
> http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 

Oxford University Press (UK) Disclaimer

This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. OUP does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of OUP. If this email has come to you in error, please delete it, along with any attachments. Please note that OUP may intercept incoming and outgoing email communications.