Re: white space in xsd:hexBinary

On Jan 16, 2012, at 1:16 PM, Noah Mendelsohn wrote:

> 
> On 1/16/2012 3:00 PM, Liam R E Quin wrote:
>> (1) define your own type, and in XSD derive it from xs:string with a
>> constraining facet
> 
> Yes, but this is at least a bit misleading insofar as the value space for xs:string is, well, strings, and the precedent with schema is that numeric types have numeric value spaces.

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; 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, while critics of XSD use it to criticize XSD for not making 
it possible to validate things that users in fact would like to be able 
to validate, and which do not in fact pose any particular difficulty
for validation (beyond the fact that XSD doesn't provide the
necessary primitive notions).

It says here that the main drawback to deriving a type from
string for hexadecimal representations of binary with embedded
white space is that you can't talk about it in public without someone
grabbing your elbow to say that such a type is "misleading" because
of wa wa and wa wa.  

A secondary drawback may be that a consuming application 
may need two or three lines of code to generate the appropriate 
value for internal use from the string value, instead of using two 
or three lines of code (possibly fewer, probably more) to extract 
the appropriate value for internal use from a non-standardized 
API for schema processors.


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Received on Monday, 16 January 2012 21:14:04 UTC