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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Restrictions on existence of attributes?

[ Lists Home | Date Index | Thread Index ]

Jack,


Le mercredi 05 juillet 2006 à 20:26 -0400, Jack Lindsey a écrit :
> Rick:

> However, I think I am correct in saying that, while Relax NG can
> import W3C data types, neither it nor any other DSDL module supports
> inheritance in data structures, i.e. the equivalent of WXS
> substitution groups with complex type derivation by extension.  This
> may seem like the ultimate expression of gentrification [1], but I
> fear that, unless you have any plans for an optional module in this
> area, that alone could rule you out as a mainstream contender, because
> these days inheritance seems to be ubiquitous in data modelling of all
> kinds, call it supertype-subtype, generalization-specialization or
> class hierarchy, e.g.
> 
> - Dave Hay's patterns
> - Java-fueled UML everywhere you turn
> - Len Silverston's Party Model showing up everywhere, including UMM
> ebXML Core Components
> - the ebXML Registry Information Model itself
> - OAGIS extensions
> - CPSIN, the Canadian equivalent of the GJXDM [2]
> 
> And JAXB or better still XMLBeans can effectively generate Java class
> hierarchies that exploit the inheritance features of WXS schemas.

RELAX NG (and DSDL in general) focuses on validation and, as far as
validation only is concerned, RELAX NG provides pattern combination
mechanisms that are equivalent to W3C XML Schema derivation and
substitution groups.

Let's see on a simple example...

We have the following base type:

W3C XML Schema:

    <xs:complexType name="BaseType">
        <xs:sequence>
            <xs:element name="FirstName" type="xs:token"/>
            <xs:element name="LastName" type="xs:token"/>
            <xs:element name="Mail" type="xs:token" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>

Equivalent RELAX NG (compact syntax):

BaseType =
    element FirstName { xsd:token },
    element LastName { xsd:token },
    element Mail { xsd:token }? 

Equivalent RELAX NG (XML syntax):

  <define name="BaseType">
    <element name="FirstName">
      <data type="token"/>
    </element>
    <element name="LastName">
      <data type="token"/>
    </element>
    <optional>
      <element name="Mail">
        <data type="token"/>
      </element>
    </optional>
  </define>

1) Derivation by extension:
++++++++++++++++++++++++++

W3C XML Schema:

    <xs:complexType name="ExtendedType">
        <xs:complexContent>
            <xs:extension base="BaseType">
                <xs:sequence>
                    <xs:element name="Password" type="xs:token"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

Equivalent RELAX NG (compact syntax):

ExtendedType =
    BaseType,
    element Password { xsd:token }

Equivalent RELAX NG (XML syntax):

  <define name="ExtendedType">
    <ref name="BaseType"/>
    <element name="Password">
      <data type="token"/>
    </element>
  </define>

2) Derivation by restriction:
++++++++++++++++++++++++++++

W3C XML Schema:

    <xs:complexType name="RestrictedType">
        <xs:complexContent>
            <xs:restriction base="BaseType">
                <xs:sequence>
                    <xs:element name="FirstName" type="xs:token"/>
                    <xs:element name="LastName" type="xs:token"/>
                </xs:sequence>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

Equivalent RELAX NG (compact syntax):

RestrictedType =
    element FirstName { xsd:token },
    element LastName { xsd:token }

Equivalent RELAX NG (XML syntax):

  <define name="RestrictedType">
    <element name="FirstName">
      <data type="token"/>
    </element>
    <element name="LastName">
      <data type="token"/>
    </element>
  </define>

3) Substitution group:
+++++++++++++++++++++

W3C XML Schema:

    <xs:element name="Root">
        <xs:complexType>
            <xs:sequence>
                <xs:element ref="Head"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    
    <xs:element name="Head" type="BaseType"/>
    
    <xs:element name="Restricted" type="RestrictedType" substitutionGroup="Head"/>
    
    <xs:element name="Extended" type="ExtendedType" substitutionGroup="Head"/>

Equivalent RELAX NG (compact syntax):

Head = element Head { BaseType }
Restricted = element Restricted { RestrictedType }
Extended = element Extended { ExtendedType }
start = element Root { Head | Restricted | Extended }


Equivalent RELAX NG (XML syntax):

  <define name="Head">
    <element name="Head">
      <ref name="BaseType"/>
    </element>
  </define>
  <define name="Restricted">
    <element name="Restricted">
      <ref name="RestrictedType"/>
    </element>
  </define>
  <define name="Extended">
    <element name="Extended">
      <ref name="ExtendedType"/>
    </element>
  </define>
  <start>
    <element name="Root">
      <choice>
        <ref name="Head"/>
        <ref name="Restricted"/>
        <ref name="Extended"/>
      </choice>
    </element>
  </start>

So what?
+++++++

These schemas are equivalent (*) ***AS FAR AS VALIDATION IS
CONCERNED***.

What is missing from the RELAX NG schemas are the declarations of
intention that RestrictedType is a restriction of BaseType and that
Head, Restricted and Extended belong to the same substitution group.

These notions have been left out of RELAX NG because, like mentioned in
one of my previous mails, RELAX NG has made no exception and has
rejected any feature that isn't related to validation and, again, these
schemas validate the same set of documents (*).

If these notions are important for an application, it should be noted
they are very easy to add through annotations, for instance:

namespace oo = "http://ns.xmlschemata.org/object-orientation/";

BaseType =
  element FirstName { xsd:token },
  element LastName { xsd:token },
  element Mail { xsd:token }?

ExtendedType =
  BaseType,
  element Password { xsd:token }

[ oo:restricts = "BaseType" ]
RestrictedType =
  element FirstName { xsd:token },
  element LastName { xsd:token }
Head = element Head { BaseType }

[ oo:substitutionGroup = "Head" ]
Restricted = element Restricted { RestrictedType }

[ oo:substitutionGroup = "Head" ]
Extended = element Extended { ExtendedType }

start = element Root { Head | Restricted | Extended }

Or in the XML Syntax:

  <define name="RestrictedType" oo:restricts="BaseType">
    <element name="FirstName">
      <data type="token"/>
    </element>
    <element name="LastName">
      <data type="token"/>
    </element>
  </define>
.
.
.
  <define name="Head">
    <element name="Head">
      <ref name="BaseType"/>
    </element>
  </define>
  <define name="Restricted" oo:substitutionGroup="Head">
    <element name="Restricted">
      <ref name="RestrictedType"/>
    </element>
  </define>
  <define name="Extended" oo:substitutionGroup="Head">
    <element name="Extended">
      <ref name="ExtendedType"/>
    </element>
  </define>
  <start>
    <element name="Root">
      <choice>
        <ref name="Head"/>
        <ref name="Restricted"/>
        <ref name="Extended"/>
      </choice>
    </element>
  </start>

The first annotation (oo:restricts = "BaseType") is a declaration that
RestrictedType must be considered as a restriction of BaseType. As any
annotation, it would be ignored by RELAX NG processors, but could be
enforced by a tool that would check that this represents a real
restriction of its base type (a number of papers have been published
with algorithms to do so).

The second annotations oo:substitutionGroup="Head" are declarations that
Head, Restricted and Extend belong to the same substitution group. In
this example they are redundant with the choice between the three
elements from the substitution group but you could also define the Root
element as:

start = element Root { Head }

or

  <start>
    <element name="Root">
      <ref name="Head"/>
    </element>
  </start>

and write a XSLT transformation that would process the
oo:substitutionGroup annotations to replace references to Head by
choices. The downside is that the schema before expansion would validate
a different set on instances.

These are only two examples of how annotations can be used to facilitate
the use of RELAX NG for modeling purposes. These two examples mimic W3C
XML Schema features, but annotations are more powerful than there is no
reason to limit their use to what is supported by W3C XML Schema.

Annotations are being more and more widely used in programming languages
and I think that for the same reasons we have a lot to gain by using
them in XML schema languages as well. 

Eric

(*) The W3C XML Schema schemas and RELAX NG schemas are not strictly
equivalent in that the RELAX NG schemas do not allow xsi attributes.

-- 
GPG-PGP: 2A528005
Le premier annuaire des apiculteurs 100% XML!
                                                http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=





 

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

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