W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2011

Re: Followup on the processor graph discussion of yesterday ( on ACTION-53 , related to ISSUE-67 )

From: Toby Inkster <tai@g5n.co.uk>
Date: Fri, 04 Feb 2011 12:52:16 +0000
To: Ivan Herman <ivan@w3.org>
Cc: W3C RDFa WG <public-rdfa-wg@w3.org>
Message-ID: <1296823936.12475.69.camel@ophelia2.g5n.co.uk>
On Wed, 2011-02-02 at 11:42 +0100, Ivan Herman wrote:

> Toby, does not this address your concern?

Not especially. There are environments where a processor can be sure
that the processor graph will never be needed. For example, it's a
component in a larger piece of software, and that software's design is
such that it will never need or request the processor graph. According
to the spec, it still needs to have code that generates these triples,
even if they'll never be used?

The fact that some processors will have a processor graph and some will
not is an interoperability concern, yes. But the question is, is it a
big enough concern that we should add extra normative statements to the
specification? I say no.

If I'm writing an application and need to swap the RDFa library I'm
using with a different one, it's unlikely that whether they both support
a processor graph will be at the top of my concerns. Number one would
probably be whether or not the new library is in the same programming
language as the first - because using a library written in X from an
application written in Y is usually not trivial. The paradigm it uses
for retrieving data will be another concern - does it fire off a
callback function for each triple encountered, or does it wait until the
end and provide me with a single graph object as the result? If the
latter, what are the methods by which I can inspect and manipulate the
graph object? And so on.

If swapping between libraries, whether they both support the processor
graph feature might be a single concern out of a long list. But assuming
we need to be concerned at all by the items on that list, they're really
API concerns, not Core concerns.

While it's plainly clear that setting minimum standards for what a
processor graph must contain will be a great boon for interoperability,
I really do not see what we gain by making the processor graph required.
Leave it optional. People who are writing general purpose RDFa
processing libraries will probably want to implement this feature. (I
plan on doing so.) But those people who are writing more specialist RDFa
processors and know they won't need it, why should we say that they're
not compliant? If I just want to write an app that finds
dc:license/cc:license/xhv:license triples and stores them in a big table
like this:

    document                  | license
    --------------------------+------------------------
    http://example.com/       | FDL 2.0

Then why do I need to generate a processor graph?

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
Received on Friday, 4 February 2011 12:53:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:08 GMT