[Bug 6644] Context determined type table

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





--- Comment #3 from Hans-Juergen Rennau <hrennau@yahoo.de>  2009-04-15 23:06:11 ---
(In reply to comment #2)
I think 3.4.4.5 "Conditional Type Substitutable in Restriction" deals with
extension too, in spite of its title. Therefore the example presented seems to
me appropriate.

The resolution of bug #6561 *seems* to fix the problem which the concrete
example presented above poses. This is so because a skip wildcard is used. But
after replacing it with a lax wildcard, we get these phenomena:

1. the element declaration of e2 is correct according to 3.8.6.3 (because it
does not use type tables), but will yield any element instance invalid (because
3.4.4.5 does compare type definitions, in the absence of type tables)

2. if the local element declaration of b (or the global one) included a
"redundant type table" stating the type definition as the default and not
containing alternatives - then suddenly the element declaration of e2 would be
inconsistent according to 3.8.6.3 part 2.

And now with the latest correction - xs:anyType does not create any
context-determined type table - we get a further twist:

3. the example as presented above yields element instances invalid; but if we
collapse the two steps of derivation into one, getting

  <xs:complexType name="t2">
    <xs:sequence>
      <xs:element name="a" type="xs:string"/>
      <xs:any processContents="lax"/>
      <xs:element name="b" type="xs:date"/>
    </xs:sequence>
  </xs:complexType>

I think the element instances that were found invalid (due to 3.4.4.5
Conditional Type Substitutable in Restriction) are again valid (clause 1: "if
TB does not exist => constraint is satisfied"). 

So if *one* of the purposes of 3.4.4.5 was to disallow one element name to be
associated with different types within a complex type, this purpose is
sometimes met, sometimes not: it depends on how the matches (wildcard and
element declaration) are distributed over derivation steps. So I think it is
inappropriate to try let 3.4.4.5 do a job *beyond* safeguarding the consistency
of proper type tables within derivation chains: better leave a job alone, than
do it unreliably, occasionally, undermining the confidence in what is correct
and what is not.

I suppose there is a general feeling that the present state of affairs is not
quite as clear as one might wish. Perhaps there is just no real improvement in
sight, and one should leave things as they are.

So I really do not know if the following proposal would be an improvement - but
at any rate you might consider it as an option:

!
Change the definition of context-determined type table in such a way that an
element does not have a CDTT unless it does contain a type table (that is,
dropping clause 2.2)
!

Advantage: than the rules dedicated to safeguard the consistency of type tables
(3.4.4.5 and 3.8.6.3) would be clear and without contradiction. The basic
concept of consistent type tables would be: the elements in question must
either all have compatible type tables - or all have no type tables.

Disadvantage: 3.4.4.5 would cease to help ensure that one element name cannot
be associated with several types (in case concurrent element declaration and
wildcard) within a complex type.

But, as I tried to point out, the disadvantage is perhaps an illusionary one,
as the safeguarding function of 3.4.4.5 is unreliable. The proposal would
reduce 3.4.4.5 to this purpose: safeguard the consistence of type tables within
derivation chains.


-- 
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 Wednesday, 15 April 2009 23:06:26 UTC