Re: Comments on the API document (version of Monday

Hi Ivan,

> [...]
>
> I think that there should, somehow, two ways of 'creating' or accessing the whole
> RDFa environment. One way should be one step and should return a reasonable default
> setup. The other way is the detailed setup where the user can specialize along the way.
> The latter is obviously for advanced users only; the former is obviously a wrapper around
> the latter with default settings.

Yes, that's exactly right.

But we should be clear that the thing we have to really get right is
the more complex version, because that determines the life-cycle of
the whole architecture. We have to be sure that we've got the
interactions correct, and then we can put a wrapper around the whole
thing.

(Of course we achieve this by developing the two things in parallel --
the detailed setup, and the wrapper.)


> [...]
>
>> See "modularity and pluggability" in this section:
>>
>> http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/Overview.html#the-design-goals
>
> Hm. To provoke: who and when decided that we need that as a design goal? I do not
> remember having this discussion... If the price for this level of modularity and pluggability
> is a very complex API that the community will reject, than we would loose on long term.
> In my view, simplicity may be more important.

Yes, we love simplicity.

But I have been trying to flag up that the first thing the HTML5
community will ask is *when* things happen: when is parsing
initiated...when is data available to be queried...and so on.

(The reason I'm certain of this, is because a key design goal of the
HTML5 project is to provide consistency in browsers, so they have put
a lot of effort into defining how ambiguous markup is processed, how
things should act in the event of failure, and so on.)

Library developers will also ask us similar questions, but from a
different standpoint; if I want to write an hCard parser that adds
triples to the core RDFa store, when can I do it in the parser's
lifecycle? And how do I access that store to drop my triples in?

One of my key issues with the previous API was that we didn't address
this, and I think that the best way to do so is to define the parts
that make up the architecture.

Then you can express the necessary detail for the lifecycle...and
/then/, when you have that, you can provide 'simplicity' to the
programmer and end-user, by wrapping the whole thing in simple
interfaces.


> [...]
> My understanding is that the property group is all about all the triples bound to one subject. If so,
> than the origin should be the DOM node for that subject...

That's right for the origin of a property group, but we sometimes want
the origin of a predicate/object.

Thanks again for your comments!

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 20 May 2010 12:53:29 UTC