[Bug 6561] Type Substitutable in Restriction

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





--- Comment #11 from Hans-Juergen Rennau <hrennau@yahoo.de>  2009-03-03 07:37:45 ---
(In reply to comment #9)
> Perhaps I am just too dim to understand it, but I don't see what contradiciton
> arises from the example in comment #8.   If someone who has looked into the
> example in greater detail can put it in terms of "For this example, rule xyz 
> entails that A, and rule vwx entails that not(A)", I'd be grateful.
> 

Before trying to express the problem in a more general way I want to clarify a
point on which we may disagree. The matter *is* important because constraint
3.4.4.5 can destroy the validity of a document which is valid according to the
conviction of 9 out of 10 experienced users (if not 999 out of 1000). Imagine a
little ten-liner in the depth of a large project, which is called in the course
of vital system operations and which - under rare yet conceivable circumstances
- produces a null pointer exception. The ten-liner is given in three parts -
constraint 3.4.4.5 (Conditional Type Substitutable in Restriction), the
definition of CDTT and constraint 3.8.6.3 (Element Declarations Consistent).
The null pointer exception consists in rendering a perfectly healthy document
invalid. The rare but conceivable conditions are these:

- a complex type T overrides a global Element Declaration by a local one (call
its name E)
- T is derived from another type B whose content model does not reference 
element E (so T either adds E as part of an extension, or narrows down a
wildcard to E as part of a restriction) 
- B's content type contains a wildcard matched by E

This constellation seems to me ordinary. Yet chances are that the validity of
any element validated against T will be destroyed if it has a child E! This is
because constraint 3.4.4.5 compares the type associated with E (according to
the CDTTs) in B on the one hand, and in T on the other hand. If T extends B,
these types even have to be equal - which probably will not be the case, as T
chose to override the global element declaration.

You asked about the "contradictions". 

Contradiction 1: Constraint 3.8.6.3 (Element Declarations Consistent)
explicitly states that strict and lax wildcards restrict the freedom of using a
type table in a locally redeclared element; the constraint implies that skip
wildcards do not restrict this freedom. But constraint 3.4.4.5 means that skip
wildcards do restrict the freedom! The difference is esoteric, but it may
decide who will have a conversation with the boss: a strict or lax wildcard
causes a schema error detected when processing 3.8.6.3, while a skip wildcard
causes an instance document invalidity, detected when processing 3.4.4.5.

Contradiction 2: Constraint 3.4.4.5 is meant (I believe) to ensure that the
possibility of redefining type tables within a derivation chain does not
compromise the concept of restriction, that is, the principle that any instance
valid against the restricted type is valid against the base type. The effect
however is introducing invalidity in cases where type tables are not even used
and the "restriction principle" is not at all threatened. This is a
contradiction to common sense.

By the way: the present state of our ten-liner means that documents valid
according to schema 1.0 become invalid according to schema 1.1. You discourage
me from giving a further example. But I think I might present *real world
examples* where nothing looks eccentric.


-- 
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 Tuesday, 3 March 2009 07:37:56 UTC