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

ISSUE-50: TypedLiteralConverter modifier parameter [RDFa 1.1 API]

From: RDFa Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 27 Oct 2010 01:31:45 +0000
To: public-rdfa-wg@w3.org
Message-Id: <E1PAurh-0007P5-8d@crusher.w3.org>

ISSUE-50: TypedLiteralConverter modifier parameter [RDFa 1.1 API]


Raised by: Nathan Rixham
On product: RDFa 1.1 API

Spec Issue:
"The RDFa Working Group is still discussing whether or not having a modifier is a good idea as 90% of use cases will never use it and the remaining use cases could provide the functionality with an external switch to the conversion function."

  remove "modifier" from DataContext.convertType and TypedLiteralConverter.convert
  change return of registerTypeConversion from void to TypedLiteralConverter.


interface DataContext {
    void setMapping (in DOMString prefix, in DOMString iri);
    TypedLiteralConverter registerTypeConversion (in DOMString iri, in TypedLiteralConverter converter);

    IRI  resolveCurie (in DOMString curie);
    any  convertType (in DOMString value, in optional DOMString inputType);

[NoInterfaceObject Callback]
interface TypedLiteralConverter {
    any convert (in DOMString value, in optional IRI inputType);

TypedLiteralConverter usage:

function myStringIntConverter(value,inputType) {
  // implementation which returns a string representation
  // of an int rather than a native int
var context = document.data.context;
// get the native converter and register a custom one
var nativeConverter = context.registerTypeConversion('xsd:int', myStringIntConverter);
// work with data
context.registerTypeConversion(nativeConverter); //return to native mode

The above should handle any use case which the modifier parameter could handle, without needing an additional parameter.
Received on Wednesday, 27 October 2010 01:31:51 UTC

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