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

Re: ISSUE-57: TypedLiteralConverter Failures and Exceptions

From: Nathan <nathan@webr3.org>
Date: Thu, 28 Oct 2010 20:12:53 +0100
Message-ID: <4CC9CB35.8050908@webr3.org>
To: RDFa Working Group WG <public-rdfa-wg@w3.org>
RDFa Working Group Issue Tracker wrote:
> ISSUE-57: TypedLiteralConverter Failures and Exceptions
> 
> http://www.w3.org/2010/02/rdfa/track/issues/57
> 
> Raised by: Nathan Rixham
> On product: 
> 
> The RDFa API document currently states:
> 
> "The return value upon conversion failure is being actively discussed in the RDFa WG. There are proposals to raise exceptions upon conversion failure, proposals to return tuples containing conversion success/failure and the converted value, as well as other mechanisms that would allow the signalling of a conversion failure from the method to calling code."
> 
> After implementing it is clear that Exceptions should not be thrown, and that TypedLiterals *must* always be created, valueOf() functionality is additional functionality provided by the API, however this is not a requirement of parsing RDFa Documents, a TypedLiteral can be created regardless of having TypedLiteral conversion.
> 
> Another proposal is that failures in conversion are handled the same as TypedLiterals which have no converter registered.
> 
> Which raises the issue that we have not defined what valueOf() should return when no appropriate TypedLiteralConverter is registered.

I've been thinking about TypedLiteral.valueOf() functionality in more 
detail, and looking at the implementation, and came to the conclusion 
that I think it should be removed.

valueOf() suffers from the same unknown-coupling problem that is found 
in a few of the other interfaces, such as the create*** methods.

To illustrate:

   var object = x.createTypedLiteral("1234", "xsd:integer");
   x.registerTypeConversion("xsd:integer", myintconverter);
   object.valueOf();

Which TypedLiteralConverter does object.valueOf() use? the one which 
existed on the context when it was created? the new one? what if there 
are 3 contexts? and so forth

We're not actually loosing any functionality by removing it, just 
clearing up a few errors, as DataContext.convertType can still be used, 
and when DataContext.convertType is used, it's unambiguous.

Any comments?

Best,

Nathan
Received on Thursday, 28 October 2010 19:14:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:22 UTC