OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   W3C XML Schema best practice : inclusions

[ Lists Home | Date Index | Thread Index ]
  • From: Eric van der Vlist <vdv@dyomedea.com>
  • To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
  • Date: Mon, 06 Nov 2000 16:07:19 +0100

I'd like to introduce another topic that could be entitled: "Which
inclusion mechanism should we use for W3C XML Schema ?"

The question may seem pointless, but we have at least 4 inclusion
mechanisms that can be used in our schemas...

1) The two first ones are xsd:include and xsd:redefine.

While the difference between these two constructs is clear when we stick
to the examples mentioned in the primer [1]:

 <include schemaLocation="http://www.example.com/schemas/address.xsd"/> 

vs 

 <redefine
  schemaLocation="http://www.example.com/schemas/address.xsd">
  <complexType name="ipo:Address">
   <complexContent>
    <extension base="ipo:Address">
     <sequence>
      <element name="country" type="string"/>
     </sequence>
    </extension>
   </complexContent>
  </complexType>
 </redefine> 

I wonder what if we need 2 constructs and what is the difference between

 <include schemaLocation="http://www.example.com/schemas/address.xsd"/> 

and

 <redefine schemaLocation="http://www.example.com/schemas/address.xsd"/> 

I am under the impression that "include" is a specific case of
"redefine" when it has empty content and that we could make the economy
of having two different elements.

2) The next ones are generic inclusion mechanisms: external parsed
entities and XInclude.

XML Schema structures says [2] for xsd:redefine --that is superset of
xsd:include-- that "the functionality no different except in scope from
what would be achieved by wholesale text copying and redefinition by
editing".

The specific semantic of xsd:include appears then to be very low and one
may wonder why a generic inclusion mechanism couldn't be used.

The obvious advantage is that generic inclusion mechanism are readable
by any supporting tool.

Note that the scope of usage of xsd:redefine that brings an extra
functionality is easier to perceive.

As an example, I have written a stylesheet to extract all the element
definition from the W3C XML Schema schema and, because W3C XML Schema
are used in these schemas, I had to support these elements by adding
templates in my stylesheet, whereas if a generic inclusion mechanism had
been used, I could have used a XML parser supporting them to perform the
inclusion by itself.

The first obvious candidate in the second category are external parsed
entities.

The main differentiation is probably the lack of namespace awareness of
external parsed entities.

This can probably be seen both as a potential problem (what if a prefix
doesn't match what I thought it would ?) or as an opportunity for more
chameleon stuff...

External (and internal) parsed entities can be very flexible though,
allowing to include small pieces multiple times if needed.

The other obvious differentiation is that you cannot include a whole
schema (since a new xsd:schema element would then be included and would
not be the document element), but only parts of schema.

The second generic candidate is XInclude.

Here again, we would have to include parts of schema instead of a whole
schema, but could use XPointer expressions to qualify a part of a
complete schema.

One should note that W3C XML Schema does also support XPointers within
xsd:include or redefine [3]:

"1.1  If the normalized value of the schemaLocation [attribute]
successfully resolves, it resolves either 
1.1.1  to (a fragment of) a resource of type text/xml, which in turn
corresponds to a schema element information item in a well-formed
information set, which in turn corresponds to a valid schema ..."

My reading of this is that you can include, using xsd:include and a
XPointer identifying a text/xml fragment, a single element definition
such as:

<xsd:element name="foo" type="ns1:bar"/>

and that in this case, W3C XML Schema will read the schema in which it
is physically included (the well-formed information set, which in turn
corresponds to a valid schema) to associate ns1 with the namespace
defined there.

On the other hand, XInclude handling the value of the type attribute as
some text wouldn't translate it. The Xinclude spec is not very verbose
about what happens to namespaces that are not "used" [4] and this may
lead to potential problems if they are lost and if the prefix is
undefined or associated to another namespace in the including schema.

These are just some first thoughts and I have the feeling to walk on
moving grounds, but I would be interested to know what you think about
all this !

Thanks

Eric

[1] http://www.w3.org/TR/xmlschema-0/
[2] http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#element-redefine
[3] http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#compound-schema
[4] http://www.w3.org/TR/xinclude/#IDAUF3R
-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS