W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2003

Re: Redefining redefines

From: Sandy Gao <sandygao@ca.ibm.com>
Date: Thu, 12 Jun 2003 12:35:20 -0400
To: mfeblowitz@frictionless.com
Cc: www-xml-schema-comments@w3.org
Message-ID: <OF1AD36CBB.A28D726D-ON85256D43.005A0012@torolab.ibm.com>

> There are situations in which the redefinition of a type, and the
subsequent
> redefinition of the redefined type, are desirable. One such case is where
a
> schema user would like to extend a type, not just from the original
source
> but based on the extension of another schema user's extension (Company C
> extends type T from Company B, who picked it up from Company A and
redefined
> it).
>
> I notice in the Rec that this is discouraged:
>
> In all cases there must be a top-level definition item of the appropriate
> name and kind in the <redefine> <http://www.w3.org/TR/xmlschema-1/> d
schema
> document.
>           NOTE: The above is carefully worded so that multiple
> equivalent <redefine> <http://www.w3.org/TR/xmlschema-1/> ing of the same
> schema document will not constitute a violation of clause 2
> <http://www.w3.org/TR/xmlschema-1/>  of Schema Properties Correct
(§3.15.6)
> <http://www.w3.org/TR/xmlschema-1/> , but applications are allowed,
indeed
> encouraged, to avoid <redefine> <http://www.w3.org/TR/xmlschema-1/> ing
the
> same schema document in the same way more than once to forestall the
> necessity of establishing identity component by component (although this
> will have to be done for the individual redefinitions themselves).
> Indeed, XML Spy requires that the redefined schema contain a type
definition
> for a type that is to be redefined - that a redefinition is not
sufficient.
> So it is not possible to redefine a redefined type.
>
> So the question is, is this something that is likely to change, or will
> validators vary on whether or not they support cascading redefines?

Sorry for the long delay in replying to your question.

The schema working group believes that redefining redefines is allowed by
the current spec. The following forwarded message indicates the reason(s).

=====================================================

A concrete example might help:

xsd1:
<schema ...>
  <complexType name="CT">
    ...
</schema>

xsd2:
<schema ...>
  <redefine schemaLocation="xsd1">
    <complexType name="CT">
      ...
  </redefine>
</schema>

xsd3:
<schema ...>
  <redefine schemaLocation="xsd2">
    <complexType name="CT">
      ...
  </redefine>
</schema>

Apparently, xsd1 is valid, and it corresponds to a schema with 1 global
complex type component (and built-in types, of course).

xsd2 is also valid, and it corresponds to a schema with 1 global complex
type, whose base type is something similar to "CT" in xsd1, without a name.

Now the question is whether, in the current spec, there is anything (other
than the "top-level" phrase) that makes xsd3 invalid, or makes it
impossible to determine the validity of xsd3, or makes it impossible to
determine what components are in the schema corresponding to xsd3.

Let's try to follow the rules in constraints [1] and [2]:

The interesting bullets seem to be 4.1 from [1] and 1 from [2].

"4.1 If clause 3.1 or clause 3.2 above is satisfied, then the schema
corresponding to SII' must include not only definitions or declarations
corresponding to the appropriate members of its own [children], but also
components identical to all the ·schema components· of I, with the
exception of those explicitly redefined (see Individual Component
Redefinition (§4.2.2) below)."

and

"1 The <simpleType> and <complexType> [children] information items each
correspond to two components:
1.1 One component which corresponds to the top-level definition item with
the same name in the <redefine>d schema document, as defined in Schema
Component Details (§3), except that its {name} is ·absent·;
1.2 One component which corresponds to the information item itself, as
defined in Schema Component Details (§3), except that its {base type
definition} is the component defined in 1.1 above."

a. I don't see anything that makes xsd3 invalid.
b. It's clear that the schema of xsd3 includes 1 global complex type CT,
whose base type is the CT in xsd2 (without a name, of course).

Now if another schema document or an instance document references xsd3
(include, import, redefine), xsd3 is nothing different from any other
schema document. It just corresponds to a schema that contains some
components. The fact that it redefined something, or it redefined something
that was redefined doesn't not concern the document referencing it.

Another case is that some document references both xsd3 and either xsd1 or
xsd2. But this is handled in the same way as if some document references
both xsd2 and xsd1: an error of duplicate globals.

Now back to R-123. Unless someone finds something else in the spec that
contradicts with what I figured, I'm going to draw the conclusions that:
1. The commentator's concern isn't necessary. Redefining redefines is
allowed by the current spec.
2. The spec is clear about how redefining redefines is handled. Nothing
needs to be clarified.
3. The spec does have an error with regard to the lack of the definition of
"top-level". This, IMO, should be classified as a future requirement.

[1] http://www.w3.org/TR/xmlschema-1/#src-redefine
[2] http://www.w3.org/TR/xmlschema-1/#src-expredef

Thanks,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com
Received on Thursday, 12 June 2003 12:35:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:01 UTC