[rdfaapi] Notes on TypedLiteralConverters

A TypedLiteralConverter is an object that is passed to the
DataContext.registerTypeConversion() method:

  <http://www.w3.org/TR/2010/WD-rdfa-api-20100608/#idl-def-TypedLiteralConverter>

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
this:

  var context = document.data.context;

  context.registerTypeConversion(
    "xsd:integer",
    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:

  "23"^^xsd:integer

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
group.

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.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

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