- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 16 Jan 2012 18:57:35 -0500
- 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 request.) > 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. Noah
Received on Monday, 16 January 2012 23:58:06 UTC