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

Re: ISSUE-57: TypedLiteralConverter Failures and Exceptions

From: Nathan <nathan@webr3.org>
Date: Mon, 01 Nov 2010 10:49:54 +0000
Message-ID: <4CCE9B52.40806@webr3.org>
To: RDFa Working Group WG <public-rdfa-wg@w3.org>
CC: Toby Inkster <mail@tobyinkster.co.uk>
Nathan wrote:
> 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.

Proposal to resolve ISSUE-57:

(1) Remove TypedLiteral.valueOf()

(2) Change the relevant methods on DataContext to:

interface DataContext {
...
   any                    convertTypedLiteral( in TypedLiteral 
typedliteral );
   TypedLiteralConverter  registerTypeConversion( in DOMString type, in 
TypedLiteralConverter converter );
...
}

convertTypedLiteral
  - typedliteral a TypedLiteral to convert

functionality:
if a TypedLiteralConverter is registered for the .type of the 
typedliteral then try to convert it, if successful return the converted 
type (for instance a Date)
in all other cases (including exceptions) return the TypedLiteral

registerTypeConversion
  - type can be an IRI or a CURIE
  - tlc can be a TypedLiteralConverter or null

functionality:
(remove a converter by passing in null, if a converter exists for the 
type return it):
if type is a curie then resolve it to an iri
let the value of old-converter be null
if a TypedLiteralConverter is already registered for the specified type, 
then set the value of old-converter to be that TypedLiteralConverter
remove all registrations for the specified type
if the value of converter is not null, register the converter for the 
specified type
return old-converter;


(3) If the create** methods are on the same interface (ISSUE-51), then 
change the definition of createTypedLiteral to:

TypedLiteral    createTypedLiteral (in any value, in optional DOMString 
type);

createTypedLiteral
  - value, can be one of the native types for which we've specified a 
converter must be registered (Date, Number types, Boolean) or a DOMString
  - type, required if value is a DOMString

in other words we can allow:

   x.createTypedLiteral(123.45);
   x.createTypedLiteral( new Date() );

Best,

Nathan
Received on Monday, 1 November 2010 10:50:40 UTC

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