W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2012

Re: white space in xsd:hexBinary

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Mon, 16 Jan 2012 18:57:35 -0500
Message-ID: <4F14B96F.6090207@arcanedomain.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
CC: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, Henry Story <henry.story@bblfish.net>, www-xml-schema-comments@w3.org

On 1/16/2012 4:25 PM, Henry S. Thompson wrote:
> Yes, but it's a benign incompatibility, in that it does not render any
> 1.0-schema-valid documents schema-invalid.  Do we have examples where
> incompatibility in this direction has provoked pushback?

I certainly can't say there's been specific pushback from a particular user 
(this case has just come up), but it would be plausible that people have 
built downstream software that would fail or wind up with tainted data in 
databases if schema processors suddenly start allowing spaces where they 
were previously disallowed.  Whether that's a serious problem in practice, 
I can't say, but we should at least give it some thought and perhaps ask 
around in the community to find out. I suppose we could advertise this as a 
backwards incompatibility with XSD 1.0, go back to CR with it, and if 
nobody objects, go ahead. (I do hate to see us go back to CR, but except 
insofar as backwards compatibility is an issue, this seems like a sensible 

> I'm querying because I have some sympathy with the request, stimulated
> in part in reaction to Liam's post, in that hexBinary is _not_ in fact
> a numeric type, in that it's not derived from decimal, and its value
> space is not a number, it's a sequence of octets.  As such, allowing
> additional whitespace internally is not a particular stretch
> semantically.

That makes sense. I'm not at all against the change either, as long as we 
can check all the edge cases, such as the one mentioned above, and satisfy 
ourselves that there won't be significant problems in practice.

Received on Monday, 16 January 2012 23:58:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:12 UTC