Re: ISSUE-28: RDFa API issues

Hi Manu,

Thanks for the reply - comments inline..

Manu Sporny wrote:
> 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. :)

fun to do as well!

> On 06/24/2010 11:59 AM, Nathan wrote:
>>
>> 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.

ty

>> 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.

Doesn't that mean that you can only have at most (1) DocumentData and 
that can at most have (1) DataContext?

To implement this functionality outside of a browser it appears that 
you'd need to make both DocumentData and DataContext singleton's - and 
it kind of makes think that the DataContext methods should instead be on 
DocumentData..

Personally, it certainly makes sense to only have a single set of type 
converters and curie map's for a given instance of an application - but 
expressing that practically, let alone in WebIDL seems a bit of a challenge!

>> 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.

a pointer or semi-replication of the ECMAScript example from the 
Callback section of WebIDL [1] might clarify

http://www.w3.org/TR/WebIDL/#Callback

>> 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".

Does the type need to specified? and if it's remote stores then surely 
you'd need more params - perhaps the fact that a store must implement 
the DataStore interface to be used is enough, then the type doesn't 
matter - you can just pass in anything that implements the needed 
methods / properties.

>> 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.

Cool, would request a little note added like the other properties have 
to say that it should be a string formatted IRI/CURIE though (and indeed 
which or both of these are allowed).

>> 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.

Great, that makes more sense!

Best,

Nathan

Received on Friday, 25 June 2010 14:34:13 UTC