- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 05 Dec 2011 17:58:37 -0500
- To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
- CC: Henri Sivonen <hsivonen@iki.fi>, www-xml-schema-comments@w3.org, HTML Data Task Force WG <public-html-data-tf@w3.org>, RDFa WG <public-rdfa-wg@w3.org>, public-html-xml@w3.org
On 12/5/2011 3:37 PM, C. M. Sperberg-McQueen wrote: > Not quite true; the lexical space of numbers in XSD does not > (as that technical term is defined by that spec) contain any > whitespace at all. But almost true: for some types, the literal > is processed according to the value of its whitespace facet > before it is checked against the lexical space; it is this which > allows<e> 42</e> to be valid when e is declared as having > type integer. To further clarify what Michael says above: the XSD specification is in two parts, structures and datatypes, as you all likely know. One of the reasons is that the datatypes are intended to be usable not just with Schema Structures, but in other languages as well. With that background... The schema numeric datatypes do >not< include leading or trailing whitespace in the lexical forms. Period. (Well, almost period, as explained below.) Schema structures, I.e. the XSD validation language for XML, does typically provide for whitespace processing of elements and attributes that have numeric types (and many other atomic and list types.) So, when an attribute is given a numeric type The reason I hedged on saying "period" above, is that the specifications are layered in a somewhat confusing way. The datatypes specification >does< define the whitespace facet, and sets out the definitions of the facet values "preserve", "replace", and "collapse". It then, effectively, defers to the specification for the language that uses the types to determine whether the facet is accepted and enforced. Schema structures does, of course, act on the whitespace facet. So, the net effect is that for an attribute declared in an XSD schema to be, say, xs:integer, leading and trailing whitespace are not considered when parsing and validating per the lexical space for the type. It's been a long time, but I'm pretty sure I have this right. Noah
Received on Monday, 5 December 2011 22:59:09 UTC