- From: Nathan <nathan@webr3.org>
- Date: Thu, 28 Oct 2010 20:12:53 +0100
- 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