Re: RDFa API - adding Namespace

Toby Inkster wrote:
> On Mon, 11 Oct 2010 09:19:43 +0100
> Nathan <> wrote:
>> perhaps if we ask "why not add it?", is there a good reason not to?
> Antoine de Saint Exupery (author of one of my favourite books) wrote:
>  Il semble que la perfection soit atteinte non quand il n'y a
>  plus rien à ajouter, mais quand il n'y a plus rien à retrancher.
> Which is usually translated into English as:
>  Perfection is achieved, not when there is nothing more to add,
>  but when there is nothing left to take away.
> While perfection is certainly too ambitious a target, I do think we
> should be guided by the principle of less-is-more. A smaller API spec is
> going to be easier to implement, resulting in a greater number of
> implementations, and hopefully fewer places for bugs to hide.
> The API spec needs to tread a careful path between minimal and useful.
> There are some things that clearly need to be in it, but when something
> seems optional we need to ask what percentage of users are actually
> going to use it, and might they be better served by layering a
> library on top of the API to provide syntactic sugar and shortcuts?
> Bear in mind that this:
>  function NS(p){return function(s){return p+s}}
> is less than 50 characters.

I fully agree, hence why I suggested simply changing the return type of 
context.setMapping, FWIW the implementation in the API is as simple as 
setting the return of context.setMapping to:

    return function(s){return createIRI(p+s)}

That's with strict typing, returning an IRI rather that a string, which 
is needed. This approach also keeps all CURIE resolution central, in 
that usage is as follows:

   var foaf = context.setMapping('foaf','http://..')

   foaf('name') == context.resolveCurie('foaf:name')

Apologies, but I'm really failing to see how this constitutes a big 
change, how it can introduce bugs, how it can make the implementation or 
documentation any more difficult and also how this can be classed as 
`not useful` - indeed imho it's so useful that practically every lib 
will include the functionality, quite possibly with conflicting 
functionality (some returning strings, others IRIs, each having 
different function/method names) - sounds to me like just the kind of 
thing that needs standardized.

That said, I don't want to stretch out debating this as introducing in 
to the API or handling out with the API are both very minor tasks, if 
there's no consensus to add this and WG members feel strongly that it's 
a bad idea to return a CurieResolver from context.setMapping rather than 
Void, then so be it.



Received on Tuesday, 12 October 2010 00:08:44 UTC