How to derive a type (in an extended schema using <redefine>) effectively augmenting <choice> or <all> particles

Colleagues,

     Are there other ways to address the question that Harold Boley has?
(And did I make any error in my suggestions to him?)
     His question is "How to derive a type (in an extended schema using
<redefine>) effectively augmenting particles accepted by <choice> or
<all>".
               Regards,
               Bob

Bob Schloss
10/11/2001 07:24 PM

To:   Harold Boley <boley@informatik.uni-kl.de>
cc:   "Benjamin Grosof" <bgrosof@mit.edu>, stabet@nisusinc.com
From: Bob Schloss/Watson/IBM@IBMUS
Subject:  Re: XML Schema's extension mechanism  (Document link: Bob
      Schloss)

Harold,

     It is good to hear from you.  You are correct: you cannot extend,
in a <redefine> or in a derived type, an <all> or <choice>.

     Here are various ways that people are getting around this:
1) For <choice>:
    People are writing content models that have a particle which is a ref
    to a global element.  In their extension schemas, they are adding
    other global elements and using substitutionGroup attribute on their
    definitions pointing back to the original global element.  Of course,
    this means that the element tag that appears in the instance document
    is modified, not just the content model.
2) For <all> contained inside one particle of a larger complexType
    People are using <group ref="name"/> in the larger complexType
    and not defining the group name in that schema.  A different schema
    contains the definition <group name="name"><all>...</all></group>
    and then each version of schemas is distributed as a schema that
    first includes the correct schema that defines the groups and then
    includes the schema that refered to them from particles.
3) If you want to be very free with making up namespace URIs, there
    are games that can be played using wildcards.  For example, you
    extend a sequence which has a single particle which is a wildcard,
    and change which namespaces it accepts.



               Regards,
               Bob


Harold Boley <boley@informatik.uni-kl.de>@dfki.uni-kl.de on 10/10/2001
01:43:48 PM

Sent by:  boley@dfki.uni-kl.de


To:   schloss@watson.ibm.com
cc:   "Benjamin Grosof (E-mail)" <bgrosof@mit.edu>, stabet@nisusinc.com
Subject:  XML Schema's extension mechanism



Hello Bob Schloss,

Recently we finished a very preliminary Schema for the
Datalog subset of RuleML 0.8. It is accessible and initially
documented here:

http://www.dfki.de/ruleml/inxsd0.8.html

We now want to continue by using XML Schema's modularization
mechanisms (redefine) for the hierarchy of 12 RuleML 0.8 sub-
languages. But it seems as if XML Schema's extension mechanism
only allows extensions of sequences, not of xsd:all or xsd:choice.

The clearest (negative) statement I found to this effect is:

http://lists.xml.org/archives/xml-dev/200106/msg00088.html

This would force us to copy some datalog definitions into hornlog,
even though they should be 'composed' ('inherited') from datalog.

In the old DTD version, 'composition' worked with the crude but general
INCLUDE/IGNORE mechanisms for redefining entire pieces of DTD.

Do you have any hint that might help us out here?

Best regards,

Harold Boley

Deutsches Forschungszentrum für Künstliche Intelligenz
Erwin-Schrödinger-Straße
PF 20 80
D-67608 Kaiserslautern
phone:  +49-631-205-3459
fax:    +49-631-205-3210
e-mail: boley@informatik.uni-kl.de
url:    http://www.dfki.uni-kl.de/~boley

Received on Friday, 12 October 2001 10:10:58 UTC