This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5905 - vc:typeAvailable and vc:typeUnavailable
Summary: vc:typeAvailable and vc:typeUnavailable
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: PC Windows NT
: P1 minor
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2008-07-29 14:58 UTC by Michael Kay
Modified: 2008-09-09 20:17 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2008-07-29 14:58:01 UTC
I'm struggling with the semantics of vc:typeAvailable and vc:typeUnavailable.

One might expect that one can write two alternative elements, one with vc:typeAvailable="A B C" and one with vc:typeUnavailable="A B C", and exactly one of the two will be chosen. But this is not the case. The first attribute causes the element to be used if and only if ALL the types are available, while the second causes it to be used if and only if ALL the types are unavailable.

I think it would be much more useful and intuitive for these attributes to be complementary. I think that vc:typeUnavailable should cause the element to be used if ANY of the types is unavailable. That is, it is ignored if and only if all the types are available, which means changing the wording to:

vc:typeUnavailable = T, where every item in the ·actual value· T is the expanded name of some type definition ·automatically known· to and supported by the processor

and similarly for vc:facetUnavailable. [We might want to spell out that the universal quantifier is always true for an empty set.]

In the common use case where the list is of length one the meaning is unchanged.
Comment 1 David Ezell 2008-08-08 16:22:24 UTC
Note: the WG believes that fixing this bug will not invalidate anyone's review, and would not change anyone's decision about whether or not to approve the REC.
"The WG believes that this change will not invalidate any last-call reviews."
Comment 2 David Ezell 2008-08-18 14:39:03 UTC
On 2008-08-08 the WG agreed to adopt the change suggested by MK above, i.e. to make the two operations complementary.
Comment 3 C. M. Sperberg-McQueen 2008-09-09 15:29:09 UTC
A change proposal intended to resolve this issue (and others) was adopted
by the XML Schema WG on 5 September 2008.  

  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5904etc.html

Accordingly, I am marking the issue RESOLVED.  

Michael, as the originator of the issue, you can indicate your assent to the
disposition of the issue by closing it, or your opposition to the 
disposition by reopening the issue.  If we don't hear from other in two
weeks, we'll assume you are content.  Thank you.
Comment 4 Michael Kay 2008-09-09 20:17:57 UTC
Marking as closed.

Editorially, I still have great difficulty reading this text: to my mind, it has too many double negatives. I think the problem is that the attribute defines the conditions under which the element is included, whereas the spec describes the conditions under which it is ignored. To fix this I think one has to write:

An element in a schema document that has an attribute vc:typeAvailable, vc:typeUnavailable, vc:facetAvailable, or vc:facetUnavailable, is to be ignored, along with all its attributes and descendants, unless one or more of the following is true: 

   1. The element has a vc:typeAvailable attribute T, and every item in the ·actual value· of T is the expanded name of a type definition ·automatically known· to the processor
   
   2. The element has a vc:typeUnavailable attribute T, and some item in the ·actual value· T is not the expanded name of a type definition ·automatically known· to and supported by the processor

...
   
(I'm not sure this is quite the same outcome as the current text if more than one of these attributes is present, but that's a questionable situation anyway...)