W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > December 2011

Re: <time> values in HTML5

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Mon, 05 Dec 2011 17:58:37 -0500
Message-ID: <4EDD4C9D.4010008@arcanedomain.com>
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 

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.

Received on Monday, 5 December 2011 22:59:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:28 UTC