W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2007

[Bug 4189] [FS] technical: 8.1.9 Type expansion correct?

From: <bugzilla@wiggum.w3.org>
Date: Wed, 10 Jan 2007 19:12:17 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1H4irx-0004QJ-DH@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4189

           Summary: [FS] technical: 8.1.9 Type expansion correct?
           Product: XPath / XQuery / XSLT
           Version: Proposed Recommendation
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: hrennau@yahoo.de
         QAContact: public-qt-comments@w3.org


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.
Received on Wednesday, 10 January 2007 19:12:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:32 UTC