RE: Ambiguous values.

As Ashok says, order matters for union type.  I received an internal query 
as to where the spec says this.  It's at [1]:

"[Definition:]   The datatypes that participate in the definition of a 
·union· datatype are known as the memberTypes of that ·union· datatype. 

The order in which the ·memberTypes· are specified in the definition (that 
is, the order of the <simpleType> children of the <union> element, or the 
order of the QNames in the memberTypes attribute) is significant. During 
validation, an element or attribute's value is validated against the 
·memberTypes· in the order in which they appear in the definition until a 
match is found. The evaluation order can be overridden with the use of 
xsi:type. "

If your union specifies integer first, then +22 will be valid per that 
type, and will have a value space value which is indistinguishable from 
the integers "22", "022", etc.  If your union specifies string first, then 
your value will be the character string with the three characters "+", 
"2", "2". 

There is a related set of details regarding fixed values.  The 
specification is also clear on this:  they refer to the value space, not 
the lexical form.  See [2]:

"Validation Rule: Attribute Locally Valid 

For an attribute information item to be locally ·valid· with respect to an 
attribute declaration all of the following must be true:
1 The declaration must not be ·absent· (see Missing Sub-components (§5.3) 
for how this can fail to be the case). 
2 Its {type definition} must not be absent. 
3 The item's ·normalized value· must be locally ·valid· with respect to 
that {type definition} as per String Valid (§3.14.4). 
4 The item's ·actual value· must match the value of the {value 
constraint}, if it is present and fixed."

The definition of "actual value" is [3]:

"[Definition:]  The phrase actual value is used to refer to the member of 
the value space of the simple type definition associated with an attribute 
information item which corresponds to its ·normalized value·. "

So, rule 4 above and this definition make clear that if an attribute has a 
"fixed" value of "+22", then that will also validate "22" for an integer, 
or a union in which integer comes first, but not a string or the other 
form of the union.

The specifcation does try to cover all these cases.  If you are interested 
in this level of detail, I suggest you read it (indeed, one reason the 
specification tends to be long and a bit dense is that it does cover most 
of these details.)  Thank you.



[1] http://www.w3.org/TR/xmlschema-2/#atomic-vs-list
[2] 
http://www.w3.org/TR/xmlschema-1/#section-Attribute-Declaration-Validation-Rules
[3] http://www.w3.org/TR/xmlschema-1/#key-vv

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







"Ashok Malhotra" <ashokma@microsoft.com>
Sent by: xmlschema-dev-request@w3.org
08/22/01 11:22 AM

 
        To:     "Kevin Yancey" <kevinyancey@hotmail.com>, <xmlschema-dev@w3.org>
        cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        RE: Ambiguous values.


Kevin:
Try to validate the value against the types contained in the union in the 
order that they
are specified in the union.  Declare victory with the first type that the 
value validates with.
All the best, Ashok 
=========================================================== 
Ashok Malhotra              <mailto: ashokma@microsoft.com> 
Microsoft Corporation 
 
 
-----Original Message-----
From: Kevin Yancey [mailto:kevinyancey@hotmail.com] 
Sent: Wednesday, July 18, 2001 9:12 AM
To: xmlschema-dev@w3.org
Subject: Ambiguous values.
 
I've been working on writing a schema parser and ran into a problem that 
doesn't seem to have been
addressed in the XML Schema specification documents.  There are certain 
situations in parsing an XML
Schema (or any XML document for that matter) where the meaning of a 
lexical value in an XML Schema 
would be ambiguous.  To illistrate what I mean, I'll give an example:
 
Say that a given schema defines a simple type called "unionType" that 
unions the built-in types "decimal" 
and "string" (the usefullness of such a type may seem insignificant, but 
nothing I see in the specification 
prohibits it).  Then, lets say that an attribute declared in the schema 
has unionType as its type and also has 
a fixed value defined for it of "22".  The value "22" could mean the 
string "22" or the number 22.  The difference 
between the two becomes relevant if this attribute declaration is applied 
to an attribute with a value of "+22". 
"+22" is the same as "22" numerically, but not the same as a string. 
Therefore, the attribute could be valid 
with respect to the schema, depending on how the schema's ambigous value 
is interpreted.
 
One resolution to this problem might be to simply disallow unions whose 
members have overlapping lexical
spaces.  This is easy when dealing with simple types such as string and 
decimal, but if the member types
we derived from them, it would be difficult to impossible to detect with 
certainty such union types with all
the facets there are to take into account.
 
For validation purposes, the distinction between values in the document 
being validated becomes mute, since
"48" is still a valid decimal value, whether the writer of the doucment 
meant the string "48".  The validator only
cares if the given lexical value is valid for the specified type.  The 
distinction becomes critical, however, when
interpreting the schema itself, for reasons given in the example above. 
Similar problems arise with the use of
the enumeration facet as well.
 
So, in a nut shell, my question is, how is an schema parser to tell the 
difference between values when
encountering ambiguous values such as is the case in the example above?
 
Any comments are welcome,
    Thanks,
 
    Kevin P. Yancey
    Balance Wheel Technologies Inc.

Received on Wednesday, 22 August 2001 13:30:21 UTC