Re: An RDFa API Diagram and some questions...

On 06/01/2010 09:54 AM, Ivan Herman wrote:
> So, I spent some time today trying to get my head around the mutual
> dependencies of the current interfaces. I am of a visual type, so I
> created a diagram. I attach this diagram; I am _not_ saying that this
> has to be put into the document, but it certainly helped me to grasp
> the dependencies and maybe it is useful for others.

I think it would be useful if we put this diagram (or something very
close to it) into the RDFa DOM API document. Whether we do this before
FPWD or after isn't that important (to me, at least)... just that we put
the diagram in there. It really does help show which interfaces are related.

> Looking through the structure I also discovered two issues/questions.
>
> - The DataIterator interface is fairly 'isolated' on the diagram; at
> the moment it is used only by the Parser (unless I missed something).

Nope. It's only used by the DataParser.

> First of all, I am not sure what the role of the 'iterator' method is
> on the parser interface (I have asked that before).

Being pedantic - it's the .iterate() method, not the .iterat*or*()
method. Benjamin does a good job of clarifying what this method is meant
to do in a reply to your original e-mail.

Basically - it's a less memory intensive way to extract triples from the
page.

> Also, looking at
> other interfaces I realized that the DataStore.filter method returns
> a DataStore. Wouldn't it be more logical if filter returned an
> iterator instead (my understanding is that the DataIterator.next()
> can be used to get to the next triple)?

Perhaps... the rationale was that .filter() can transform one DataStore
into another (more specific) one. .iterate() just runs through a
document - no dependency on having a data store of any kind.

You could have .filter() return an iterator, but it would be an iterator
over a datastore - no memory would be saved since all triples are coming
from a pre-build data store.

That said, I can understand your viewpoint...

> - I wonder about the rdfa interface (section 5.3.4). While there is a
> fairly logical relationship now with
>
>     Document->DocumentData->{store,context, etc}

That section is marked for deletion... we don't need .getElements() at
all. I'm not certain we need .containsRDFa() - but Benjamin had a few
use cases for that particular item. I haven't thought about where to
move it yet, but the general desire is that that "rdfa." interface
should disappear completely. We just need to decide on whether or not we
should remove .containsRDFa() completely, or keep it around. I'd like to
remove it - you don't need to check to see if there is/isn't RDFa. You
do your query and if there is no data, there is no RDFa and thus you do
nothing in your Javascript.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP
http://blog.digitalbazaar.com/2010/05/06/bitmunk-3-2-2/2/

Received on Wednesday, 2 June 2010 02:37:49 UTC