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

[Bug 6170] New: Wildcards and defaultAttributes

From: <bugzilla@wiggum.w3.org>
Date: Fri, 17 Oct 2008 09:03:22 +0000
To: www-xml-schema-comments@w3.org
Message-ID: <bug-6170-703@http.www.w3.org/Bugs/Public/>


           Summary: Wildcards and defaultAttributes
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: mike@saxonica.com
         QAContact: www-xml-schema-comments@w3.org

In, XML Mapping summary, property {attribute uses}, it is stated

If the <schema> ancestor has a defaultAttributes attribute, and the
<complexType> element does not have defaultAttributesApply = false, then the
properties {attribute uses} and {attribute wildcard} are computed as if there
were an <attributeGroup> [child] with empty content and a ref [attribute] whose
·actual value· is the same as that of the defaultAttributes  [attribute].

For completeness, it needs to say whether this hypothetical <attributeGroup>
child is at the start or the end. This is because when multiple attribute
groups are combined, and more than one of them has an attribute wildcard, the
effective processContents is taken from the first.

(This is a horrible rule, but it's the only one we've got. I've argued in WG
email (see
http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2008Oct/0009.html -
member-only) that at least for defaultAttributes the result should be the union
rather than the intersection, and by analogy with derivation by extension, the
processContents would then be that of the extended type rather than the base

Configure bugmail: http://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 Friday, 17 October 2008 09:03:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:12 UTC