Re: ISSUE-69 (datatype sizes): datatype sizes

This would force implementations to discard information.

What is the problem with R2RML's approach here, which is “check your DB manual for the maximum length of a VARCHAR, or else pick an arbitrary large number”?

> Unfortunately, these mappings are all subject to vender-specific width limitations, which means that implementors have no idea what to implement in order to interoperate with other implementations.

Why do they have no idea? It says you're supposed to implement whatever the DB vendor says.

Best,
Richard


On 30 Sep 2011, at 15:36, RDB2RDF Working Group Issue Tracker wrote:

> 
> ISSUE-69 (datatype sizes): datatype sizes
> 
> http://www.w3.org/2001/sw/rdb2rdf/track/issues/69
> 
> Raised by: Eric Prud'hommeaux
> On product: 
> 
> http://www.w3.org/2001/sw/rdb2rdf/track/issues/48 was resolved by following the SQL spec's lead for generating XML from SQL datatypes. Unfortunately, these mappings are all subject to vender-specific width limitations, which means that implementors have no idea what to implement in order to interoperate with other implementations. The Direct Mapping LC provides fixed numbers for these mappings,
>  http://www.w3.org/TR/2011/WD-rdb-direct-mapping-20110920/#defn-literal_map
> but these have not been subject to WG review. Justifications for these selections were:
>  type       width  reason
>  xsd:decimal  18   http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal says minimum is 18
>  xsd:integer  18   lexical restriction of decimal doesn't affect width
>  xsd:double   23   maximum characters for an IEEE754 double (i.e. xsd:double)
>  xsd:date     13   limited to under 100k years, e.g. +100000-01-01
>  xsd:time     23   10E-14 second precision, e.g. 01:23:45.67890123456789
>  xsd:dateTime 37   sizeof(xsd:date)+sizeof("T")+sizeof(xsd:time)
> 
> The choices of 10E6 years and 10E-14 seconds are arbitrary. We could limit to common cases like CCYY for years, and microsecond precision for time, noting that extensions to dates should follow the conventions in ISO8601. That would reduce widths to 10 and 15, putting dateTimes as 26.
> 
> 
> 
>

Received on Friday, 30 September 2011 17:20:20 UTC