ISSUE-28: RDFa API issues (was: Re: New Issue(s))

Hi Nathan,

Thanks for the feedback, I've tried to collect a full reference to your
issues into ISSUE-28. I still need to go back and comb the list to make
sure we are properly tracking all of the various issues that have been
raised. This is not official feedback from the RDFa WG.

Apologies for the omissions beforehand - I think only Ivan has gotten
around to implementing the spec, so you're the first canary in the mine.
Thank you for forging on ahead, early implementations of the RDFa API
are invaluable. :)

On 06/24/2010 11:59 AM, Nathan wrote:
> I've came across a few issues which are confusing me a little (after
> trying to prototype an implementation) - issue 2 is the real
> puzzler/blocker..
> 
> 1: This documentation looks a bit wrong..
>   DataStore.createPlainLiteral( value, language );
>   value  DOMString  The value of the IRI. The value can be either a full
> IRI or a CURIE.
> ?? the value of a PlainLiteral must be an IRI or CURIE ??

That is wrong, we'll fix this in the next release.

> 2: CURIE resolution..
> 
> var contextA = document.data.createContext();
> var contextB = document.data.createContext();
> contextA.setMapping( 'a' , 'http://example.com/a#' );
> contextB.setMapping( 'a' , 'http://example.com/b#' );
> var store = document.data.createStore();
> var triple = store.createTypedLiteral( 'something' , 'a:test' );
> 
> will that a:test resolve to:
>   http://example.com/a#test -or- http://example.com/b#test ?

That is unknown, or more precisely, the only way to affect CURIE
resolution is to overwrite the document.data.context parameter. You have
created two contexts above, but neither one overrides
document.data.context unless you assign either contextA or contextB to
document.data.context. In other words:

document.data.context = document.data.createContext();
document.data.context.setMapping('a', 'http://example.com/a#');

would make "a:test" resolve to "http://example.com/a#test"

> the same issue arises for registerTypeConversion, if I created two
> different functions to handle a type of xsd:whatever then which would be
> used?

Same answer for this one, the only context that matters is
document.data.context.

We'll try to add language to make this more clear in the next release.

> 3: TypedLiteralConverter
> Just how would one create a new TypedLiteralConverter? There's no
> constructor, and further DataContext.registerTypeConversion needs an
> instance of TypedLiteralConverter but specifies that the converter param
> should be 'A function that converts..' (indicating
> TypedLiteralConverter.convertType or a callback rather than an instanceof)

Good point, that's an error.

Ideally, we'd pass registerTypeConversion() a pointer to a function. I
don't know how to cleanly specify that in WebIDL. We need to fix this in
the next release.

> 4: DocumentData.createStore( type ) - what's the type for? why is it not
> nullable and not optional when no examples actually pass in a param?

Another good catch. That value should be nullable and optional.

The type is meant to provide support for the creation of not only
TripleStores, but QuadStores, RemoteRestStores and LocalStorageStores.
In other words - the DataStore is an interface and implementations may
provide their own "types" to provide more than just in-memory data stores.

I'm still not convinced that this is the best way to approach the
problem, but until a better solution comes along, we'll keep it in the
document.

We need to address the issue you mentioned and we need to better
document the reasoning behind "type".

> 5: Document.getElementsByType(type) and getItemsByType(type) where type
> is a DOMString, should this not be IRI or CURIE?

Nope. The interface to the API is supposed to be string-based - we don't
want to have to make developers create a new IRI object from a string
and pass that IRI into the method. We just use strings for everything
that we can - jQuery sets a good example to follow.

> 6: How does one create a new DocumentData instance? there's no way to
> set the .store/context/parser/query properties (they're all readonly)

Another good catch - they should all be read/write, not readonly.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Myth Busting Web Stacks - PHP is Faster Than You Think
http://blog.digitalbazaar.com/2010/06/12/myth-busting-php/2/

Received on Friday, 25 June 2010 13:26:00 UTC