Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


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

From: "C. M. Sperberg-McQueen" <cmsmcq@-------------.--->
To: Rick Jelliffe <rjelliffe@-------.---.-->
Date: 4/26/2009 11:21:00 PM
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
****************************************************************





_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent