W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2000

Re: [Priority Feedback] More issues with <redefine/>

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Wed, 27 Dec 2000 11:42:42 -0700
Message-Id: <4.3.2.7.1.20001227113556.028f7b28@espanola.com>
To: "Asirv" <Asirv@webmethods.com>
Cc: "Www-Xml-Schema-Comments@W3. Org" <www-xml-schema-comments@w3.org>, "Ningang chen" <nchen@webmethods.com>
At 2000-12-19 13:50, Asirv wrote:
>YES, 'including modified component definitions' is a powerful feature. But,
>it raises several issues. These are subtle and critical issues. I will
>attempt to describe them as clearly as possible. If they are not clear,
>please ask me questions.
>
>[1] NAMESPACE COERCION
>
>During namespace coercion, the targetNamespace of this example's
>corresponding schema information item (SII) is the targetNamespace of
>redefining SII. If this latter targetNamespace is present (namespace
>coercion happens), wild card components, A and B, produce undesired (or
>catastrophic) results. Because, these components were processed before
>redefinition.

Where does the spec require a particular sequence of processing?

>[2] IMPACT on ANONYMOUS TYPE DEF's {content type} whose BASE DEFINITIONS
>were redefined
>
>This can be best illustrated using an example. Sir, please pardon me if the
>syntax is incorrect.
>
>v1.xsd:

Looks correct to me.  I did have to change a line or two to make
it validate, but that's because I used explicit namespace prefixes
for clarity.

>v2.xsd:
>  <xs:redefine schemaLocation="v1.xsd">
>   <xs:complexType name="personName">
>    <xs:complexContent>
>     <xs:extension base="personName">
>      <xs:sequence>
>       <xs:element name="generation" minOccurs="0"/>
>      </xs:sequence>
>     </xs:extension>
>    </xs:complexContent>
>   </xs:complexType>
>  </xs:redefine>
>
>  <xs:element name="author" type="personName"/>
>
>In the above example, before redefinition, addressee declaration component
>has the following content,
>
><!ELEMENT addressee (title?, forename*, surname)>
>
>First, Part 1 does not say what happens to the anonymous complex type of
>addressee declaration component after redefinition.

It seems to me to be pretty clear about what happens.

>Intuitively, I would
>expect it to be,
>
><!ELEMENT addressee (title?, forename*, generation?, surname)>

Yes.

>Second, it is impossible (using the given mapping rules) to construct the
>above declaration component after redefinition. Because, the addresee
>declaration component, its anonymous complex type and {content type} were
>computed before redefinition.

What do you mean?  Where in the spec does it say that the complex type
of addressee is "computed before redefinition"?  If it does say this, I
believe it's an editorial error, because the entire point of the
redefinition-in-place construct (both the proposal we adopted and
the counter-proposal we didn't adopt) was to have the result be as
you describe above:  generation gets inserted between forename and
surname.

C. M. Sperberg-McQueen
Received on Wednesday, 27 December 2000 14:02:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:49 GMT