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

[Bug 8119] New: defaultAttributes and complexType extension/restriction don't play nice

From: <bugzilla@wiggum.w3.org>
Date: Wed, 28 Oct 2009 21:14:06 +0000
To: www-xml-schema-comments@w3.org
Message-ID: <bug-8119-703@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8119

           Summary: defaultAttributes and complexType extension/restriction
                    don't play nice
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: David_E3@VERIFONE.com
        ReportedBy: kbraun@obj-sys.com
         QAContact: www-xml-schema-comments@w3.org
                CC: cmsmcq@blackmesatech.com


Consider this XSD 1.1. schema:

<xs:schema
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   defaultAttributes="AttrGroup"
>

   <xs:attributeGroup name="AttrGroup">
      <xs:attribute name="a_default" type="xs:string"/>
   </xs:attributeGroup>

   <xs:complexType name="TypeA">
   </xs:complexType>

   <xs:complexType name="TypeB">
      <xs:complexContent>
         <xs:extension base="TypeA">
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
</xs:schema>


I believe this is not valid, because TypeB's {attribute uses} will have two
"a_default" attributes.  At least, this would be true if I had explicitly
defined the same attribute in TypeA and TypeB, and I don't see any exception
for default attributes.  This can be resolved by using
defaultAttributesApply="false" on TypeB, but that is both annoying and
counterintuitive (because it will still inherit the default attributes).  

Something somewhat similar happens for restrictions, but only if you try to
restrict a default attribute.  The attribute will then be present twice in
{attribute uses} - once from the default attributes group and once for the
explicit <attribute> child.  The effect seems to be that you cannot restrict a
default attribute, unless you specify defaultAttributesApply="false".  Another
situation arises if you try to restrict a type that didn't have the default
attributes.  In that case, if defaultAttributesApply="true", you'll be adding
attributes in the restriction, which will be a problem unless they happen to
restrict an attribute wildcard (as in the case of an implicit complexContent).

Perhaps default attributes should not apply to derived types (ie, act as if
defaultAttributesApply="false" were specified).  For an extension,
defaultAttributesApply="true" is only useful in a few cases, and in those
cases, the attributes could still be added by an explicit reference to the
attribute group.  For a restriction, defaultAttributesApply="true" will cause
one of the above problems or have no effect whatsoever.  Meanwhile, there
doesn't seem to be any reason to ever use defaultAttributesApply="false" for a
restriction, other than to avoid the above problems.  Yet, there is the case of
restriction of xs:anyType coming from using an implicit complexContent, where
you do want defaultAttributesApply="true".

It seems like making "defaultAttributesApply" a property of the ComplexType
component, and having some rules to set it appropriately might be a way to
solve these rather nasty problems.


-- 
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 Wednesday, 28 October 2009 21:14:18 GMT

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