This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Definition of {facets} in 4.1.2.1 Derivation by restriction: {facets} The union of the set of Facets (2.4) components resolved to by the facet [children] merged with {facets} from {base type definition}, subject to the Facet Restriction Valid constraints specified in Facets (2.4). What is being "unioned" and how does "merge" work? For example, if the base has a minLength facet with value 5 and the derived type has a minLength child facet of value 7, how many minLength facets are in the derived type's facets property? The text above makes it sound like both are present, but constraints within the rec strongly imply there is only one facet for each facet name. (For instance, reference to "*the* minLength facet" for validation constraints). Common sense suggests the last facet of a given name wins, but it's hard to get that from "union" and "merge". Related member-only thread: Facet equality: questions/issues http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Mar/0187.html See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004AprJun/0000.html
See http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004AprJun/0002.html
When this issue is dealt with, bug 2781 (which is about how Structures refers to the concept of one facet being stronger than another, which is a key concept in facet merger) should also be dealt with.
I'm reopening this issue in order to track the two-sided changes needed to resolve bug 2781, which in turn are part of satisfying this requirement fully.
*** Bug 2223 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Definition of {facets} in 4.1.2.1 Derivation by restriction: > > {facets} The union of the set of Facets (2.4) components resolved to by the > facet [children] merged with {facets} from {base type definition}, subject to > the Facet Restriction Valid constraints specified in Facets (2.4). > > What is being "unioned" and how does "merge" work? For example, if the base has > a minLength facet with value 5 and the derived type has a minLength child facet > of value 7, how many minLength facets are in the derived type's facets > property? > > The text above makes it sound like both are present, but constraints within the > rec strongly imply there is only one facet for each facet name. (For instance, > reference to "*the* minLength facet" for validation constraints). Common sense > suggests the last facet of a given name wins, but it's hard to get that > from "union" and "merge". The text above has been changed and moved in the LCWD, but the basic question is how is the set of facets of a derived type determined from the new facets added and those of the base type, and in particular (inherited from Bug 2223, whether the old facets are included. The requirement is in Structures, 3.15.6, Schema Component Constraint: Simple Type Restriction (Facets): 3 The facets of R [the restriction] [must] ·constitute a restriction· of the {facets} of B [the base] with respect to S [a set of new facets]. Within the definition of "constitute a restriction", the governing clause is: 2 Every facet in B is in R unless it is of the same kind as some facet in S. If we interpret "unless" to mean that the facet in B is prohibited if is is of the same kind as some facet in S, then reading back into the Constraint we find that the constraint precludes a facet of B from being also a facet of R if there is a facet of the same kind in S. I'd say we need at least a comment in Part 2 that nakes this process clear.
Implementing the proposal in bug 4034 formally solves the problem via a change to Part 1. A note such as the following should be added to 4.1.1: "In accordance with [appropriate reference to Structures, 3.15.6, Schema Component Constraint: Simple Type Restriction (Facets)], there can be at most one of each kind of facet in {facets}."
The XML Schema Working Group discussed this issue during its telcon of 7 September 2007. We noted that the wording of the relevant passage has changed. XSDL 1.0 and early drafts of 1.1 had {facets} The union of the set of Facets (2.4) components resolved to by the facet [children] merged with {facets} from {base type definition}, subject to the Facet Restriction Valid constraints specified in Facets (2.4). This has been changed, in the course of work on 1.1, to read {facets} The appropriate case among the following: 1. If the <restriction> alternative is chosen, then a set of Constraining Facet components constituting a restriction of the {facets} of the {base type definition} with respect to a set of Constraining Facet components corresponding to the appropriate element information items among the [children] of <restriction> (i.e. those which specify facets, if any), as defined in Schema Component Constraint: Simple Type Restriction (Facets). 2. If the <list> alternative is chosen, then a set with one member, a whiteSpace facet with {value} = collapse and {fixed} = true. 3. otherwise the empty set where 'constituting a restriction' is a hyperlink to the definition of that term in Structures. Note that both the word 'union' and the word 'merger' are now avoided. Xan Gregg, the originator of the comment, will be notified by separate email of this resolution and asked to confirm that this resolves the issue.
In email today (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2007JulSep/0113.html) Xan Gregg, as originator of this issue, confirms that he's content with the resolution. Accordingly, I'm closing this issue.