Philipp <djbulu@g...> writes:

> Hello, I want to write an XML Schema A.xsd extending infos in schema
> B.xsd which validates for the following.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <A:rootTag
>   xmlns:A="http://www.example.org/A"
>   xmlns:B="http://www.example.org/B">
>   <B:someElement>
>     <B:one>1</B:one>
>     <B:two>2</B:two>
>     <A:other>other</A:other>
>   </B:someElement>
> </A:rootTag>

> So basically, I want schema A to take an element of B and
> extend it with its own stuff (<A:other>). I expect schema B, to
> have no references to schema A (but A will naturally import B)
> Is this possible? If yes, what will the schemas look like?

Is it possible?  Well, it may be possible.  A good deal depends
on how B:someElement and its type are defined.  Several cases are
worth distinguishing.

First, if the type of B:someElement has a wildcard allowing
elements in namespace A to appear, then all you need to do is
write a schema document for namespace A, which declares
elements A:rootTag, A:other, etc., together with their types,

Second, if the type of B:someElement does not provide such a
wildcard, but does have a name (i.e. it's a top-level type, not
local to B:someElement), then you can use xsd:redefine to do
something like what you want to do.  You would write (1) a schema
document for namespace A and (2) your own schema document for
namespace B, which uses xsd:redefine to refer to the existing
schema document for B and which extends the type of B:someElement
to include references to A:other, etc., and have B:someElement
use your extended definition in place of the original definition.

For concreteness, let us assume that the type of B:someElement is
named B:T23.  Then your schema document for the B namespace would
look something like this:

<xsd:schema 
 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
 xmlns:B="http://www.example.com/B" 
 targetNamespace="http://www.example.com/B" 
 >

 <xsd:redefine schemaLocation="B.xsd">
  <xsd:complexType name="T23">
   <xsd:complexContent>
    <xsd:extension base="B:T23">
     <xsd:sequence>
      <xsd:element ref="A:other"/>
     </xsd:sequence>
    </xsd:extension>
   </xsd:complexContent>
  </xsd:complexType>
 </xsd:redefine>

</xsd:schema>

As you can see, the xsd:redefine element contains a complex type
definition for type B:T23, written as an extension of type B:T23
and extending it by adding a required occurrence of A:other at
the end of the children prescribed by the original definition.
You can add more or other elements, they can be optional, etc.,
just as you wish.  I've made it required for simplicity.

The rules of redefine mean that element B:someElement should
use this new version of type B:T23, not the original version.

If you use xsd:redefine, it's advisable to ensure that your
overall pattern of schema document inclusions, imports, and
redefines is kept very simple.  The interactions among redefine,
import, and include are underspecified in XSD (both 1.0 and 1.1),
and implementations are all over the map in their interpretations
of the rules.  Experience shows that simple cases often work
fine, and complex cases are interoperability nightmares.

A third technique allows you to avoid using xsd:redefine; again,
it depends on the type of B:someElement having a name (again,
let's assume it's called B:T23).  In your definition of A.xsd,
define a type which extends B:T23; let's call it A:T23.  The
schema document A.xsd will contain something like this:

 <xsd:complexType name="T23">
  <xsd:complexContent>
   <xsd:extension base="B:T23">
    <xsd:sequence>
     <xsd:element ref="A:other"/>
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

This means, roughly: type A:T23 is just like B:T23, except that
at the end it adds a required A:other element.  You'll notice
that it's pretty much identical to the definition given above in
the redefine example.  The differences are (1) that this appears
in a schema document for namespace A, not namespace B, so it
generates a complex type definition named A:T23, not B:T23, and
(2) instances of B:someElement will not use type A:T23 by
default, since they were declared to use type B:T23.

So in the document instance, you need to tell the validator to
use type A:T23, not B:T23:

 <?xml version="1.0" encoding="UTF-8"?>
 <A:rootTag
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:A="http://www.example.org/A"
   xmlns:B="http://www.example.org/B">
   <B:someElement xsi:type="A:T23">
     <B:one>1</B:one>
     <B:two>2</B:two>
     <A:other>other</A:other>
   </B:someElement>
 </A:rootTag>

This is just like the example you gave, with the addition of (a)
a namespace declaration for the prefix xsi and (b) the addition
of xsi:type="A:T23" on the instance of B:someElement, which
specifies that this particular instance of B:someElement has type
A:T23, not B:T23.

Since type A:T23 is derived from type B:T23, this substitution is
allowed, unless the creator of B:xsd has chosen to block it,
either by declaring type B:T23 final and thus prohibited the
definition of types which extend B:T23, or by blocking the use of
xsi:type on instances of type B:T23 or instances of element
B:someElement.

Fourth, you can just make your own copy of schema document B.xsd,
let's call it B2.xsd, which you edit to make it do what you
want. This can work whether the type of B:someElement is named or
anonymous, but it can lead to synchronization issues if B.xsd
changes and you want your version of B to change along with it.

This fourth method is perhaps the most straightforward of the
techniques, and it's brutally honest: you want to use elements in
namespace B, but you don't want them to behave as defined in
B.xsd, you want them to behave slightly differently.

I hope this helps.

Michael Sperberg-Mcqueen 

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************