Re: white space in xsd:hexBinary

On 1/16/2012 4:13 PM, C. M. Sperberg-McQueen wrote:
> This is of practical importance in cases where the schema validator
> actually provides a machine-processable representation of the value; in
> other cases (such as, I suspect, the one being discussed here) it has no
> practical importance at all.
>
> In both cases, of course, it has rhetorical importance;

Yes.

> supporters of XSD use it (as NM seems to be doing here) to suggest that
>  certain uses of XSD are misleading, incorrect, improper, and / or
> impure

Well, I certainly didn't mean to suggest it with such vehemence. I think 
it's a factor to take note of in making a decision to introduce a new type. 
If on balance, going with a subtype of string seems the best compromise, 
then fine. It likely is in this case.

If there really is a crying need for this with RDF, then one could also 
imagine taking advantage of XSD 1.1's option for introducing additional 
types into particular validator implementations [1]. So, the RDF community 
could try to convince the implementors of Saxon, Xerces, Microsoft parsers, 
XML Spy, etc. to support some new primitive type that would have the 
correct value space and would be identified as such by tooling. I didn't 
mention this in my earlier not, and hesitate to mention it now, because I 
suspect that in this case it would be difficult to get more than a few 
processors to support it, and so interoperability would likely suffer. That 
being the case, a subtype of string may indeed be the 'least of the evils'.

Noah

[1] http://www.w3.org/TR/xmlschema11-1/#sec-other-builtins

Received on Monday, 16 January 2012 23:51:33 UTC