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

Re: General feedback on the RDFa API draft

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Sat, 19 Jun 2010 14:06:07 +0100
Message-ID: <AANLkTinh5Hm7kQRxRJyFZPw6lq95frxijoja893rfT8H@mail.gmail.com>
To: nathan@webr3.org
Cc: RDFA Working Group <public-rdfa-wg@w3.org>, Manu Sporny <msporny@digitalbazaar.com>
Hi Nathan,

Many thanks for your feedback.

The goal is definitely to allow the API to be implemented
independently of the DOM, but I agree that this is not very clear at
the moment.

Perhaps if I give you the 'aim' you can see where we're headed, and
also where we currently fall short.

The idea of having a rather detailed array of interfaces (such as
Parser, Store, etc.) is so that it's easier to make clear how the
different components work together, and most importantly what their
life-cycles are. We wanted to ensure that we could answer questions
like 'when can I run a query', or 'when is parsing complete', and the
only way to do that is to drill further into the architecture and
specify more of it.

However, we also believe that the single most important use-case for
the API will be JavaScript/Ajax programmers doing clever stuff with
the data in a web-page, and for this reason we wanted to provide a set
of API definitions that would be appropriate for a DOM-based
implementation. To put it a different way, we didn't want to run the
risk of different browser-implementers deciding to combine the various
modules in incompatible ways.

So what it sounds like we need to be clearer on is that the DOM-based
part of the spec is not a requirement for all implementations of the
parser, but it is a requirement for implementations based on a DOM.

This does flag up another issue which is the 'origin' property, which
at the moment is defined as pointing to a DOM Node, and should really
be more general.

Personally I see this as a 'user-defined' property that can be used
for any purpose, and it just so happens that a DOM-based parser uses
it to point back in to the DOM. But a different parser could use it
for other purposes, which means that its name should probably be
something more generic.

Anyway, as you can see there are still things to sort out, but
hopefully you can also see that the kinds of clarifications you want
are being worked through, and comments such as yours are really useful
for helping to close in on a solution.



On Sat, Jun 19, 2010 at 12:36 AM, Nathan <nathan@webr3.org> wrote:
> Hi All,
> precursor: much of what follows may be addressed by changing the title to
> 'RDFa DOM API' and stating 'An API for extracting structured data from Web
> documents in a User Agent that implements the DOM' :)
> Without delving in to too many specifics, I'm slightly (something) that the
> RDFa API only caters for handling RDFa inside a User Agent with DOM support,
> it appears to me that the API could easily be split so that core
> functionality could be implemented in any context.
> side: To quickly touch on subject.origin (or subjectOrigin), given that one
> may pull in several resources via XHR and add them to a single DataStore,
> how would this affect the subject.origin, and moreover what about the origin
> of the triple (as in the URI/Document/NG it came from) - what we typically
> think of as the ?g in a quad.
> Back to the specific issue of 'only works if you have a DOM', here's a
> specific scenario:
> The rdflib.js from tabulator currently supports RDF/XML, N3 etc.. RDFa
> support is currently being added - this could easily be an implementation of
> the RDFa API - however the code also currently works on the server side (in
> V8, node.js and suchlike), so it's a kind of universal library, but if we
> upgraded it to use the RDFa API, then server side support would be lost.
> If however the RDFa API was created with this consideration in mind, then it
> could be implemented in not only rdflib.js, but any server or client side
> rdf library. Moreover, it would set the way to align everything but
> serialization specific parsing with RDFa API, essentially creating a one for
> all RDF API - I'm sure you can see the benefits in this, failing that even a
> one for all RDFa API that can be implemented outside of the current
> generation of User Agents would be nice.
> Apologies for introducing multiple issues for you to consider, perhaps not
> everything is in scope, and I'm unsure if it needs addressed but just some
> thoughts.
> Best,
> Nathan
Received on Saturday, 19 June 2010 13:06:45 UTC

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