W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2009

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

From: <bugzilla@wiggum.w3.org>
Date: Mon, 02 Feb 2009 02:41:21 +0000
To: public-qt-comments@w3.org
Message-Id: <E1LTokT-0008Uv-JR@wiggum.w3.org>

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





--- Comment #4 from Michael Dyck <jmdyck@ibiblio.org>  2009-02-02 02:41:21 ---
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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 2 February 2009 02:41:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:26 UTC