This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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="")?
I'm not sure what point you are trying to make. There's obviously a design choice between allowing a local element declaration to carry the attribute value abstract="false", with no other value permitted, or not allowing the attribute to appear at all. The specification clearly made the choice of not allowing it to appear. If you're simply saying you would have chosen differently, then that's nice to know, but it's not going to change anything at this stage of the game. I don't see the relevance of the rules in Element Locally Valid (Element), which say D.{abstract} = false. The spec is talking here about properties of components in the schema component model, which are only distantly related to like-named attributes of elements in a schema document.
Perhaps I'm not clear on the status of the various documents. I'm under the impression that the textual specification is the standard and that the XSD is an attempt to provide a machine-readable strategy for enforcing the standard (and therefore a second class citizen). I couldn't find anything in the standard that explicitly prohibited the attribute... and several places where its value (perhaps implied by context) was required. It therefore appears to me that the XSD seems to be more restrictive than the standard. The document states that "Comments on this document should be made in W3C's public installation of Bugzilla". Comment submitted. There are several obvious (but likely non-exhaustive) ways that my the comment could be invalid: - The XSD could be the authoritative standard - The XSD could be a first class citizen representing the intent of the textual standard (and upon consideration the desired interpretation) - The standard could include an explicit statement prohibiting the value - The standard could be designed in such a way that the prohibition is implied by existing content If one of these (or another) applies, the usual protocol is to explain which and close the issue. If none of these apply, my comment/question seems valid. My suggestion is fully backwards compatible. It's impossible to anticipate every corner case and, upon consideration, they may find my example a valid reason to change it. It's certainly not going to change if I don't point out the (perceived) problem. And if nothing is ever going to change, it would seem like a waste to keep this tracker up... let alone **subscribe** to the issues submitted to it.
The schema for schema documents is normative. There are many constraints in the schema for schema documents that are not repeated in the prose of the spec. I should point out that I responded in a private capacity. There is currently no active maintenance of this specification. Presumably someone might start work on a revision at some time in the future and will then consider the accumulated comments, but in the meantime, the best you can hope for by commenting is an explanation of why the spec is written the way that it is.