W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > June 2010

[rdfaapi] Notes on TypedLiteralConverters

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Sat, 12 Jun 2010 19:00:08 +0100
Message-ID: <AANLkTikHON1PaFAqtSLz4I-5Urh9mmV3XlX8Tvfmyf_9@mail.gmail.com>
To: RDFa WG <public-rdfa-wg@w3.org>
A TypedLiteralConverter is an object that is passed to the
DataContext.registerTypeConversion() method:


Once registered the object will be given the opportunity to convert
data-types to a native form. Here are some comments on this part of
the API:

1. We should allow languages to simply point to a function rather than
always requiring an object with a function.

When specifying DOM event handlers in a browser, the parameter can be
either an object that has the required method, or a function. If we
allowed this shorthand in RDFa API, then an example would look like

  var context = document.data.context;

    function (value) {
      return parseInt(value, 10);

(The example is approximate -- see next point.)

2. We need to be very precise about how conversions should be carried
out, so that authors know how to write conforming converters.

For example, say we have:

  "23 elephants"^^xsd:integer

In JavaScript, if we simply used the parseInt() function to process
this, we'd get 23 as the result. I.e.:

  assert.areEqual(23, parseInt("23 elephants", 10));

Setting up a type conversion using this technique would mean that a
query against the store would return a property group that has 23 as a
native type:

  { "my-pets": 23 }

However, the original did not have:


Instead, it had an invalid type. So we need to guide authors more
precisely as to how they should implement these converters.

3. The convertType() method should be given a parameter that indicates
what type is being converted.

Although it is certainly possible to write lots of individual
handlers, authors might also want to create a single routine that
handles all of their datatype conversions, and register it multiple
times. The problem is that as things stand, such a routine would have
no idea what it is attempting to convert to.

Although we could just add a second parameter to the method, I think
the easiest (and neatest) way to achieve this would be to simply pass
the original typed literal object as a single parameter. That way the
conversion method has access to any other methods and properties that
we might add to TypedLiteral in the future.

4. We need to know whether some conversion has taken place.

At the moment the spec says that if conversion can't be carried out
then the return value is the same as the value passed in. The problem
with this is that you have no idea whether anything happened, and
therefore don't know whether the result returned is usable or not. If
the API is creating a property group as the result of a search, then
we don't know whether or not to pass the value through to the property

As to what the exact mechanism for this should be, there are a number
of ways to do this, which broadly amount to the following:

* throw an exception if parsing doesn't happen properly;

* return a boolean to indicate whether conversion has succeeded or
failed, and then provide the actual return value separately. One way
to do this would be to pass in an object which has a 'from' and 'to'
property, and the function would fill in the 'to' value;

* return null if conversion failed, and the converted object otherwise.

My preference would be to return the converted object or null:

  /* Failure */
  x = createTypedLiteral("23 elephants", "xsd:integer");
  assert.isNull(convert( x ));

  /* Success */
  x = createTypedLiteral("23", "xsd:integer");
  assert.isTrue(convert( x ) === 23); /* use '===' to suppress type
conversion */

Other people may of course have other ideas.



Mark Birbeck, webBackplane



webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Saturday, 12 June 2010 18:00:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:47 UTC