[Bug 30063] New: XSD treatment of Explicit Defaults

https://www.w3.org/Bugs/Public/show_bug.cgi?id=30063

            Bug ID: 30063
           Summary: XSD treatment of Explicit Defaults
           Product: XML Schema
           Version: 1.0/1.1 both
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
          Assignee: David_E3@VERIFONE.com
          Reporter: bugzilla_w3.claytond@spamgourmet.com
        QA Contact: www-xml-schema-comments@w3.org
                CC: cmsmcq@blackmesatech.com
  Target Milestone: ---

The specification file at https://www.w3.org/2009/XMLSchema/XMLSchema.xsd has
the following definition for a localElement:

```
<xs:complexType name="localElement">
  <xs:complexContent>
    <xs:restriction base="xs:element">
      <xs:sequence>
        <xs:element ref="xs:annotation" minOccurs="0"/>
        <xs:choice minOccurs="0">
          <xs:element name="simpleType" type="xs:localSimpleType"/>
          <xs:element name="complexType" type="xs:localComplexType"/>
        </xs:choice>
        <xs:element name="alternative" type="xs:altType" minOccurs="0"
maxOccurs="unbounded"/>
        <xs:group ref="xs:identityConstraint" minOccurs="0"
maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="substitutionGroup" use="prohibited"/>
      <xs:attribute name="final" use="prohibited"/>
      <xs:attribute name="abstract" use="prohibited"/>
      <xs:anyAttribute namespace="##other" processContents="lax"/>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>
```

I'd like to draw your attention, in particular, to the "abstract" attribute.  I
believe the specification is quite clear that:

1. Its default is false: "abstract = boolean : false"
2. The value must be "false" for the validation rules to pass:

```
Validation Rule: Element Locally Valid (Element)
For an element information item E to be locally ·valid· with respect to an
element declaration D all of the following must be true:
1 D is not ·absent· and E and D have the same expanded name.
2 D.{abstract} = false.
...
```

I believe this behavior would be more accurately described using fixed="false".
 This would permit a schema to apply the default explicitly without violating
this schema.  I assume there are other cases where this applies to values with
defaults.

I ran into this issue because I had some infrastructure that was making default
values explicit (following the specification).  This made it easier to
programmatically identify equivalent structures like the following:

<element name="test" abstract="false"/>
<element name="test"/>

I'm less clear on the proper handling of final and substitutionGroup through.
Is the absence of this value logically equivalent to the inclusion of an empty
value (fixed="")?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 14 February 2017 23:46:25 UTC