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

Re: RDFa DOM API - New Editor's Draft

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 29 May 2010 13:56:45 -0400
Message-ID: <4C01555D.1060007@digitalbazaar.com>
To: RDFa WG <public-rdfa-wg@w3.org>
On 05/27/2010 06:28 AM, Ivan Herman wrote:
> - Concept diagram, 2.2.2: it is good to have, but somehow it should
> be made clear to the reader that the three arrow represent, in fact,
> and increasing level of sophistication but an average user does not
> have to know about, say, the data store. I wonder whether creating
> three diagrams (1: webapp, doc, property gorup 2: like 1 plus data
> parser and query and 3: like 2 plus data store &co) would make that
> clearer. (I know the info is in the text, but people might look at
> the diagram first...)

Heh... the three arrows were just meant to indicate that you could hit
each "level" of the API from the application. They weren't meant to
represent what you read into them, but now that you've read that into
the diagram... it makes sense. I'll try to think more about how to
improve the diagram. I don't think that splitting it up into more
diagrams will simplify things... the goal was to have one diagram that
explains everything in broad brush strokes.

> - right before section 3, the heading says "using property groups".
> Is that correct? We are talking about elements here...

That's wrong, good catch. Fixed.

> Actually, the example uses e.style.setProperty which is, I presume,
> the way to set a CSS property. But then... using 'Property' for our
> Property groups become really really confusing! I wonder whether the
> example was on our properties or not. Bottom line, we should find
> another name for Property Groups (though I do not know what...)

I agree... Mark and I have been trying to find another name for
"Property Groups" for a few weeks now... here's what we've already
discussed, and rejected:

Web Objects
Dynamic Objects
Data Objects
Structured Data Containers

Of all of them, "Web Objects" or "Wobs" are my favorite - but Mark
pointed out that Apple already has a claim to WebObjects:


> - this is just editorial: I am a bit mixed what we call high or
> low:-( Around the concept diagram you refer to the query part as 'low
> level'. In the intro of 3 you refer to 'high level':-(

Removed all occurrences of "low-level" and "high-level". These words
have been replaced with the concepts of "basic" and "advanced".
Hopefully, that will help clarify things.

> - this becomes a technical detail, but... why does the definition of
> RDFTriple use these indeces? why not something like

The index-based interface was Benjamin's idea. He wanted to be able to
access a triple as a 3-tuple. I would rather have the interface you

> interface RDFTriple {
>    readonly attribute Object subject ;
>    readonly attribute Object predicate ;
>    readonly attribute Object object ;
> }
> the usage of these indices just remind me of FORTRAN programs:-(

Yeah, not very elegant. I'm keeping it in there unless Benjamin is fine
with removing it. If not, we'll have to discuss further as Benjamin may
have some use cases in mind that I don't quite grok.

> - I need some education on the role of DataIterator in a DataParser.
> My mental model seems to be too simple: I would expect a parse
> operation to be defined on a DataStore, so that I say
> store = new DataStore() // or whatever the syntax is
> store.parse("http:....")
> and that is it.
> I obviously miss something...

The reasoning goes something like this:

"Parsing" is the job of the "Parser", not the store. To put this in
another context. We don't expect a MySQL's InnoDB store to be able to
extract information from a non-SQL source and place it into storage.
That is the job of the application - to "parse" and direct the
information into a "store".

We /could/ provide .parse() as a convenience function on DataStore and
when a parser is created, do:

store.parser = theNewParser;

but then that limits us to only having one parser associated with a
particular store when we may want to have multiple parsers associated
with a particular store.

Mark wants to put .parse() on the document.data object, so you could do


This would use the default parser (document.data.parser) to perform the
parse of the data.

At the moment, no decision has been made as to whether or not we need a
.parse() convenience method. At the moment, .parse() resides here:


At the moment, we instruct implementers to call
document.data.parser.parse() once the document is loaded. There is an
argument for not calling it (we shouldn't assume that pages have RDFa
data in them and we don't want to increase the burden of having to do
this for mobile devices).

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP
Received on Saturday, 29 May 2010 17:57:15 UTC

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