- From: <Noah_Mendelsohn@lotus.com>
- Date: Wed, 22 Aug 2001 13:21:47 -0400
- To: kevinyancey@hotmail.com
- Cc: "Ashok Malhotra" <ashokma@microsoft.com>, xmlschema-dev@w3.org
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