PROPOSAL to close ISSUE-57: TypedLiteralConverter Failures and Exceptions

If there are no objections to this proposal in 7 days, we will close
ISSUE-57: TypedLiteralConverter Failures and Exceptions.

http://www.w3.org/2010/02/rdfa/track/issues/57

This proposal is based on discussion that happened on the telecon two
weeks ago:

http://www.w3.org/2010/02/rdfa/meetings/2010-10-28#ISSUE__2d_57__3a__TypedLiteralConverter_Failures_and_Exceptions

The following changes will be made to the RDFa API:

Change #1
---------

Remove TypedLiteral.valueOf(), moving the functionality to
    DataContext.

Change #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 to a language-native type

TypedLiteral Conversion Algorithm:
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 - an IRI or a CURIE
 * converter - can be a TypedLiteralConverter or null

registerTypeConversion Algorithm:
1. If converter is null and a converter exists for the type, unregister
   the converter and return it, otherwise return null.
2. If type is a CURIE then resolve it to an IRI
2.1 Let the value of old-converter be null
2.2 If a TypedLiteralConverter is already registered for the specified
    type, then set the value of old-converter to be that
    TypedLiteralConverter
2.3 Remove the registration for the specified type
2.4 If the value of converter is not null, register the converter for
    the specified type and return the old-converter

Change #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());

This proposal asserts that we should keep the API simple and not throw
exceptions when there are conversion failures. In effect, if a given
type does not have a converter registered, the value that is passed in
is returned. This ensures that we don't have to come up with a list of
exceptions that could be thrown by the API. Conversions are associated
with the current context, which will also have a list of all CURIE
mappings, simplifying the interfaces between the APIs layers.

Please comment in 7 days from this post if you object to this proposal.
If there are no objections within 7 days, ISSUE-57 will be closed.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: WebID - Universal Login for the Web
http://blog.digitalbazaar.com/2010/08/07/webid/2/

Received on Thursday, 11 November 2010 01:28:40 UTC