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

[Bug 14416] Non-normative description of xs:override transformation

From: <bugzilla@jessica.w3.org>
Date: Tue, 27 Dec 2011 21:59:18 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1Rff3G-0003OI-Ru@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14416

--- Comment #3 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-12-27 21:59:17 UTC ---
Re-reading the transformation, I begin to wonder whether the treatment of
xsd:redefine is correct.  

Consider the following situation:

  - schema document v1 declares a type T but does not specify it further.
    So it defaults to being a vacuous restriction of xsd:anyType.
  - schema document v2 includes a redefine of v1, with a child declaring
    type T as a complex type with simple content consisting of xsd:date
  - schema document v3 includes an override of v2, with a child declaring
    type T as a complex type with simple content consisting of xsd:gYear

Schema documents illustrating this configuration are on the W3C server at

  http://www.w3.org/XML/2008/xsdl-exx/b14416-base.xsd
  http://www.w3.org/XML/2008/xsdl-exx/b14416-v2.xsd
  http://www.w3.org/XML/2008/xsdl-exx/b14416-v3.xsd

I believe that what the WG wanted in this situation was that the override 
transformation, performed with the override element in v3 as O1 and with
schema document v2 as D2, should insert v3's version of the declaration
of type T into the xsd:redefine element.

I believe the transform as currently written fails to do this, because
any redefine will be a child of xsd:schema and thus match two templates.
One template with a match pattern of 

    schema-element(xs:schema) 
    | schema-element(xs:redefine)

This template copies the element and its attributes and then calls
xsl:apply-templates on the children.  Its default priority, if I understand 
XSLT 2.0 correctly, is 0.25.

The other template has a match pattern of 

    schema-element(xs:schema)/* 
      | schema-element(xs:redefine)/*
      | schema-element(xs:override)/*

It performs a deep copy of either the current element or its replacement
in the override element, and does not call apply-templates on the
children.  Its explicit priority is 3.

In the example, the result is that the redefine element in the D2' produced
by the override transformation (as we have defined it in the spec) is
a deep copy of the redefine in v2, instead of having its children overridden 
by matching elements in the override of v3

One possible repair is to assign a priority of 5 to the template
which currently has no explicit priority.  I don't think that's likely to
break anything.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 27 December 2011 21:59:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 December 2011 21:59:25 GMT