This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Disclaimer: Frankly, I mistrust my own reasoning, because such errors as reported below should have been detected long since. Should my remark stem from some general misunderstanding, please help me understand my error. Thank you very much in advance. --- The contents of 8.1.9 Type expansion appear to me not correct. 1.) the rule statEnv |- of type TypeName expands to Type3 is incorrect (?) 2.) a further rule statEnv |- of type TypeName expands to Type3 should be included where extends is replaced by restricts (?) 3.) in the rule statEnv |- of type xs:untyped expands to Type1 extends should be replaced by restricts (?) ad 1.) ====== 8.2.2.1.3: expands to yields the union of all the type definitions of all type names derived from the input type name. The judgment #2 of the section (8.1.9) statEnv |- of type TypeName expands to Type3 yields results which do not match this expectation. Example 1: Given: define type T1 { element a } define type T2 extends T1 { element b } Sought: Type3 in of type T2 expands to Type3 I would expect: Type3 = adjusted-version (element a, element b) But the judgment yields: Type3 = adjusted-version (element b) Result obtained as follows: TypeName = T2 BaseTypeName = T1 Type1 = element b Type2 is Type1 extended with union interpretation of TypeName => Type2 = element b Type3 = adjusted-version (element b) Example 2: Given: define type T1 { element a } define type T2 extends T1 { element b? } define type T3 restricts T2 { element a } Sought: Type3 in of type T2 expands to Type3 I would expect: Type3 = adjusted-version (element a | (element a, element b) ) But the judgment yields: Type3 = adjusted-version { element b? | element a } Result obtained as follows: TypeName = T2 BaseTypeName = T1 Type1 = element b? Type2 is Type1 extended with union interpretation of TypeName => Type2 = element b? | element a Type3 = adjusted-version ( element b? | element a ) Conclusion from examples 1 and 2: It is not Type1 what should be extended, but Type1, where Type1 is (content-model-of-BaseTypeName,Type1). ad 2.) ====== Why is there no rule for the case that TypeName resolves to a type definition which restricts a base type, rather than extend it? I think the rule should be exactly like the rule presently rendered, only with extends replaced by restricts. ad 3.) ==== The rule statEnv |- of type xs:untyped expands to Type1 puzzles me Should not extends be replaced by restricts? Compare 3.5.1., and remark #2.
I agree on all three points: #1) In 8.1.10, the definition of the 'union interpretation' judgment appears to only work correctly when the input type is the "root" of a type hierarchy. #2) 8.1.9 / Semantics / rule 2 needs a 'restricts' counterpart, though I'm not certain the two rules should be as similar as you say. #3) In 8.1.9 / Semantics / rule 3 / premise 2, "extends" should be "restricts".
I've discovered another bug in the 'union interpretation' rule. Consider the case: define type TN1 { T1 } define type TN2 extends TN1 { T2 } define type TN3 restricts TN2 { T3 } The union interpretation of TN1 should be: T1 | (T1,T2) | T3 but the rule results in: T1 | (T1,(T2|T3)) i.e. T1 | (T1,T2) | (T1,T3)
I think I've found another bug in the type expansion rules (FS 8.1.9, 8.1.10), this one dealing with the treatment of 'mixed'. Consider the case: define type TN1 { T1 }; define type TN2 extends TN1 mixed { T2 }; The question is, what type does 'of type TN1' expand to? If we ignore type-adjustments other than "mixing", and we let MIXED(T) = T & text* | xs:anyAtomicType* for brevity, then I believe the answer *should* be: T1 | MIXED(T1, T2) but I believe the answer given by the current rules is: T1 | (T1, T2) because in the rules, only the OptMixed of the top-level TypeDerivation (that of TN1) affects the adjustment of the expanded type. Similarly, given: define type TN1 mixed { T1 } define type TN2 extends TN1 { T2 } then I believe the expansion of 'of type TN1' *should* be: MIXED(T1) | (T1, T2) (because "mixedness" is not inherited by derived types), but the rules give: MIXED( T1 | (T1,T2) )
I believe the following proposal solves all the problems noted above. (In this comment, I omit occurrences of "statEnv |-", just to make judgments fit in the available width.) ========== In 8.1.9 [Type expansion], replace Semantics / rule 2: TypeName of elem/type expands to expanded-QName statEnv.typeDefn(expanded-QName) = define type TypeName extends BaseTypeName OptMixed { Type1 } Type2 is Type1 extended with union interpretation of TypeName OptMixed Type2 adjusts to Type3 ------------------------------- of type TypeName expands to Type3 with: TypeName of elem/type expands to expanded-QName statEnv.typeDefn(expanded-QName) = Definition union interpretation of Definition is TypeU TypeU adjusts to TypeA ------------------------------- of type TypeName expands to TypeA Also, in Semantics / rule 3 / premise 2, "extends" should be "restricts". ========== In 8.1.10 [Union interpretation of derived types], replace the Notation and Semantics subsections with the following rules (and some appropriate prose). Also, modify the example as necessary. Definition = define type TypeName OptDerivation OptMixed { Type } inheritance due to OptDerivation is TypeI OptMixed (TypeI, Type) opt-mixes to TypeM type definitions derived from TypeName are Definition1 ... DefinitionN union interpretation of Definition1 is Type1 ... union interpretation of DefinitionN is TypeN TypeM | Type1 | ... | TypeN = TypeU ----------------------- union interpretation of Definition is TypeU ----- The auxilliary judgment inheritance due to OptTypeDerivation is Type is defined as follows: TypeName of elem/type expands to expanded-QName statEnv.typeDefn(expanded-QName) = define type TypeName' OptDerivation OptMixed { Type } inheritance due to OptDerivation is TypeI ---------------------------------------------------- inheritance due to extends TypeName is (TypeI, Type) ---------------------------------------------------- inheritance due to restricts TypeName is empty ---------------------------------------------------- inheritance due to is empty ----- The auxiliary judgment: OptMixed Type1 opt-mixes to Type2 is defined as follows: Type1 mixes to Type2 ------------------------------ mixed Type1 opt-mixes to Type2 ------------------------ Type1 opt-mixes to Type1 [This could be merged into the 'mixes to' judgment in 8.1.6.] ----- The auxiliary judgment: type definitions derived from TypeName are Definition1 ... DefinitionN is defined informally: all type definitions in statEnv.typeDefn that involve "restricts TypeName" or "extends TypeName" are returned as a list (in arbitrary order) of Definitions. ========== In 8.1.7 [Type adjustment], drop the OptMixed parameter and remove Semantics / rule 1 that handles the case of OptMixed = mixed.
At their meeting this morning, the joint WGs approved the solution proposed in Comment #4. Consequently, I'm marking this issue resolved-FIXED. If you agree with this resolution, please mark the issue CLOSED.
This issue has been entered as FS erratum E059, and the proposed fixes have been committed to the source files for the next edition of the FS document. (I had to omit the proposed changes to 8.1.7, because some rules in F.1.1 rely on the OptMixed parameter to type adjustment.) Consequently, I'm marking this issue CLOSED.