Re: can an attribute prohibited by restriction be added back through a subsequent extension?

"Dare Obasanjo" <dareo@microsoft.com> writes:

> Alessandro Triglia writes:
>> HST writes:
>>> I think we should fix this one way or another -- what do you think is
>>> best:
>>> 
>>>   1) No constraint on re-introduction;
>>>   2) No re-introduction of any kind (apparent intention of current 
>>> REC);
>>>   3) Re-introduction of unchanged originals only (what the 
>>current REC
>>>      actually says)?
>>
>>I don't see any good reason for forbidding re-introduction.  
>
> +1

The kind of argument I can see for at least forbidding type-changing
re-introduction is the following:

Suppose top-level element P has type def'n BTP, which allows optional
child C of type TC.  Now we define a type IT derived BTP which
restricts C away, then finally derive DT, again by extension, which
adds it back with type NTC, with _no_ relation to TC.  That means that
the following situation can arise:

<A>
 <C>xxx</C>
</A>

<A xsi:type="DT">
 <C>yyy</C>
</A>

The two C elements above have type defns CT and NCT respectively,
which are _not_ the same, or even necessarily related in any way.

I think the static-type-checking folks in the Query WG will be
surprised if this is possible.

In fact at least _this_ example _is_ ruled out by the existing prose,
because the putative intermediate type defn required by clause 1.5 of
[1] would violate the Element Declarations Consistent constraint.

This analysis re-inforces my original suggestion that the _status quo_
is (3) above, but also suggests that a further option deserves
consideration:

  (4) Re-introduction only with related types.

ht

[1] http://www.w3.org/TR/xmlschema-1/#cos-ct-extends
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

Received on Monday, 26 January 2004 05:00:01 UTC