Re: [xml-dev] The meaning of the "string" datatype?

["C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>]

On 15 Apr 2009, at 07:20 , Rick Jelliffe wrote:
>
> This is of course a little topsy turvy. I had a case with an  
> insurance company who received data from the agents which had  
> standard fields but the fields could contain any notation. There was  
> a separate process where people would check the fields and "re-work"  
> them into the standard notations. So the input might have
> <date>20th May, 2010</date>
> and after rework it would contain
> <date>2010-05-20</date>
>
> They were surprised to learn that they could not merely say that the  
> incoming data was a string, and then restrict this string to be a  
> date type. (Since xs:date is not a restriction of xs:string.)

To make this idea of rework performing a restriction of the input, it
would probably be better to define the input as having a type which
is in fact restricted by date.  For example, anySimpleType, or anyType.

In XSD, date is not a restriction of string for much the same reason
that in SQL, timestamp is not a subtype of VARCHAR, and in most
programming languages, date objects or structs are not restrictions
of char* arrays.

If your interlocutors were programmers, I doubt they would have found
it surprising.  If they weren't, I think it may have been a mistake
to assume that when they said 'string' they mean 'an instance of the
xsd:string datatype'; it seems rather more likely that they meant
simply untyped data.  But I wasn't there, so I don't know.

> The original XML Schemas datatype hierarchy was not designed with  
> document refinement in mind (i.e. marking up the document, passing  
> it as text through several different XML stages):

That seems odd to me; it was certainly on the minds of some in the WG.
Perhaps not on yours.

But then I think it unwise to assume that processing a document through
stages of a workflow will invariably result in restriction, or that the
input and output of a transformation will always need to be described
by the same schema.  YMMV, of course.

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