W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > May 2010

Re: Comments on the API document (version of Monday

From: Ivan Herman <ivan@w3.org>
Date: Thu, 20 May 2010 15:03:02 +0200
Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <88DF633A-AF89-4614-AA12-5FAD33EBC305@w3.org>
To: Mark Birbeck <mark.birbeck@webbackplane.com>

On May 20, 2010, at 14:44 , Mark Birbeck wrote:

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

That is fine but is the percentage of users who would want to do that?


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

O.k. I think my main concern is really the way we present these things in the current document. We have to realize that we have different constituencies and they should be treated separately. 

Ivan


> 
>> [...]
>> 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)


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf







Received on Thursday, 20 May 2010 13:02:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:47 UTC