[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schemas: Best Practices

• From: Francis Norton <francis@r...>
• To: xml-dev <xml-dev@l...>
• Date: Wed, 31 Jan 2001 17:37:55 +0000

>
> Issue: What is Best Practice for creating extensible content models?
>

Sorry to have picked up this conversation so late, but I would be very
interested in airing any design issues involved in using xsd:redefine to
extend content models.

Briefly, we have a substantial core schema, and a requirement to
customise this for various transaction partners.

We wish to use the same message structure and element names across all
partners, but the schema name and document namespace could vary.

Given these constraints I believe that the cleanest way to specify that
two different partners may have variant enumerations in their "product"
element, which is of course nested very deep in the main message tree,
is to use xsd:redefine.

Using xsd:extend or xsd:restrict alone would - I think - force me to
re-code the element declarations and enclosing definitions all the way
up to the message root.

Only xsd:redefine appears to allow me to do a spot variation. 

If I understand http://www.w3.org/TR/xmlschema-1/#element-redefine
correctly, xsd:redefine will work provided the redefined component has
no target namespace or has the same target namespace as the redefining
schema, so I have three plausible options - 

[1]     implement all potentially redefinable components in the same
target
namespace, then rely on the instance's schemaLocation attribute to
specify which extension of the overall schema should be used

[2]     implement all potentially redefinable components with no target
namespace but have an outer level wrapper which perhaps redefines the
root element with a partner specific namespace.

[3]     put it all in the noTargetNamespace!

I have included a very small demo to give the idea - it validates with
XSV.

Any comments on the suitability of this approach for this requirement?

Francis.

 

a.xsd
=====
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
elementFormDefault="qualified">
        <xsd:element name="root">
                <xsd:complexType>
                        <xsd:sequence>
                                <xsd:element name="fred" type="ab"/>
                        </xsd:sequence>
                        <xsd:attribute name="weather" use="fixed"
value="wet"/>
                </xsd:complexType>
        </xsd:element>
        <xsd:simpleType name="ab">
                <xsd:restriction base="xsd:string">
                        <xsd:enumeration value="a"/>
                </xsd:restriction>
        </xsd:simpleType>
</xsd:schema>

a.xml
=====
<root xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="a.xsd">
        <fred>a</fred>
</root>

b.xsd
=====
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
elementFormDefault="qualified">
        <xsd:redefine schemaLocation="a.xsd">
                <xsd:simpleType name="ab">
                        <xsd:restriction base="ab">
                                <xsd:enumeration value="b"/>
                        </xsd:restriction>
                </xsd:simpleType>
        </xsd:redefine>
</xsd:schema>

b.xml
=====
<root xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="b.xsd">
        <fred>b</fred>
</root>

• Prev by Date: RE: Reg Validation of xml
• Next by Date: [Ann.] XML Schema FAQ
• Previous by thread: FW: XML Schemas: Best Practices
• Next by thread: RDDL API
• Index(es):
  • Date
  • Thread