[sc34wg3] CTM: Specifying datatypes
xuan--sc34wg3--isotopicmaps.org at baldauf.org
Mon Mar 30 14:03:02 EDT 2009
Lars Heuer wrote:
> Hi Lars,
>>> Yes, I think we should allow something like
>>> def mapping($t, $q)
>>> mapping: $q^^sql:query.
>> What happens if I then use the template as follows?
>> mapping(foo, "select ..."^^xsd:string).
>> mapping(foo, "select ..."^^bar:sql-query).
>> mapping(foo, 1).
> Well, after I've written the enthusiastic "Yes, we should", I wondered
> if this is a good idea. The problem is, that the TMDM provides only
> limited support for literal values != xsd:anyURI and xsd:string. If
> someone uses
> mapping(foo, "1.0000"^^xsd:decimal)
> mapping(foo, 1.0000)
> the result should be (according to TMDM which forbids normalization of
> mapping: "1.0000"^^sql:query.
> but a more sophisticated Topic Maps engine may produce:
> mapping: "1.0"^^sql:query.
> since the value of "1.0000" can be translated to "1.0" (canonical form
> of the xsd:decimal value).
> So, we need a policy how to translate a value from one datatype to
> another. The canonical representation would be an option but since it
> is not mentioned in the TMDM, I wonder if this policy is doable.
> Requiring that the string which was provided by the user is kept,
> would be wrong imo.
We can make it very simple:
An attempt to set the datatype only succeeds either if the old
datatype is xsd:string or if the old datatype equals the new
datatype, otherwise such an attempt is an error.
The purpose of overriding datatypes is to make it possible to write
typed strings as template-arguments without providing the type
information over and over again.
The purpose of overriding datatypes is not to create all kinds of fancy
conversions between the values, neither syntactic conversions nor
semantic conversions nor anything inbetween (e.g. conversion to
What do you think about limiting the scope of overriding datatypes for
cases where string literals were used (as outlined above)?
> I tend to join Graham's fan club and leave CTM as it is (regarding
> this issue) just to avoid the ugliness of translating literals from
> one datatype to another.
> Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sc34wg3