ISSUE-28: Re: 3 Minor issues spotted

On 06/19/2010 10:31 AM, Nathan wrote:
> During my previous exercise I spotted a few little things, as follows:
> DataContext::setMapping (in DOMString prefix, in DOMString iri);
> Perhaps could be
> DataContext::setMapping (in DOMString prefix, in IRI iri);

When creating the RDFa API, we wanted to ensure that most of the API
could be utilized by using strings. In other words, we didn't want to
make people create IRI objects just to pass them into the RDFa API
methods when a simple string would convey the information needed by the
RDFa API. In other words, this:

DataContext.setMapping("foaf", "");

is better than this:

DataContext.setMapping("foaf", IRI(""));

Does that rationale resonate with you?

> Perhaps these two methods could have their signatures aligned (predicate
> - probably tying in with the above, all DOMString or all IRI):
> DataStore::filter(in Object? subject, in optional IRI? predicate
> DataParser::iterate(in Object? subject, in optional DOMString? predicate

'IRI? predicate' was a bug, thanks for catching that - it's been changed
it to 'DOMString? predicate'.

There is another request floating out there to change all of these from
'DOMString' to just 'string', which I think would be a good move. I
haven't made the change yet because I don't know if WebIDL 'string'
supports i18n (I assume it does, but wanted to double-check before
making the change). This change would be a step towards a unified RDF
API in non-browser environments.

> DocumentData has the createParser( type , store ) method, but DataParser
> has no constructor which accepts a type, or any way of setting the type.

I have added a property called "type" to the Data Parser interface.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: WebApp Security - A jQuery Javascript-native SSL/TLS library

Received on Sunday, 1 August 2010 18:53:32 UTC