This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16874 - Change in meaning of final="#all" on elements between 1.0 and 1.1
Summary: Change in meaning of final="#all" on elements between 1.0 and 1.1
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: David Ezell
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2012-04-27 15:02 UTC by Priscilla Walmsley
Modified: 2012-11-23 17:29 UTC (History)
1 user (show)

See Also:


Attachments

Description Priscilla Walmsley 2012-04-27 15:02:50 UTC
In version 1.0, there was the following paragraph (in section 3.3.1): 

"An empty {substitution group exclusions} allows a declaration to be nominated as the {substitution group affiliation} of other element declarations having the same {type definition} or types derived therefrom. The explicit values of {substitution group exclusions} rule out element declarations having types which are extensions or restrictions respectively of {type definition}. If both values are specified, then the declaration may not be nominated as the {substitution group affiliation} of any other declaration."

The last sentence of this paragraph says that if final="#all", or final="restriction extension", then the declaration may not be the head of a substitution group, period.

In version 1.1, the equivalent paragraph is:

"An empty {substitution group exclusions} allows a declaration to be named in the {substitution group affiliations} of other element declarations having the same declared {type definition} or some type ·derived· therefrom. The explicit values of {substitution group exclusions}, extension or restriction, rule out element declarations having types whose derivation from {type definition} involves any extension steps, or restriction steps, respectively. "

The last sentence has been removed, so it seems to mean that if final="#all" or final="restriction extension", the members cannot have types that are derived by restriction or extension from the head, but it is perfectly OK to have members that have the exact same type as the head.

I can see why such a change would be made; it doesn't make sense to have "restriction extension" mean anything more than just the union of what "restriction" and "extension" would mean individually.  But this change is backward-incompatible and doesn't appear to be listed in Appendix G, so I wanted to confirm that it was intentional.  If so, it should be added to Appendix G.

Also, I am surprised to not find a more formal definition of what the "final" attribute means for elements. Section 3.3.6.1 says "subject to the blocking keywords in M.{substitution group exclusions}" but I don't see where it describes exactly what those keywords mean, except in the paragraph quoted above, which is somewhat informal.

By contrast, for example, {disallowed substitutions} has a paragraph informally describing it, but also has a clause in section 3.3.6.3 formally saying what it means if it contains the keyword "substitution".
Comment 1 David Ezell 2012-05-04 16:12:00 UTC
Resolved:  This change was made as a result of bug 3888, and there should be an item added to substantive changes.
Comment 2 C. M. Sperberg-McQueen 2012-10-20 21:09:26 UTC
A diffed version of the spec showing a draft erratum for this issue is now on the server at

  https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.errata-2012.html
  (member-accessible link)

The WG did not want to review this text, so I'm marking this bug as 'needs publication'.

Priscilla, if you could, please review the resolution of the issue and let us know whether you have any objections to it.  If we don't hear from you in the next two weeks or so, we'll assume you are happy with the changes.
Comment 3 Priscilla Walmsley 2012-10-21 15:16:54 UTC
This looks good to me.  Thanks!
Comment 4 C. M. Sperberg-McQueen 2012-11-23 17:29:26 UTC
Since PW has already indicated her agreement to the change, I'm going ahead and closing this issue on her behalf.