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: Ivan Herman <ivan@w3.org>
Date: Fri, 4 Feb 2011 14:45:52 +0100
Cc: W3C RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <479E956C-BC77-443F-A304-C440A46187C3@w3.org>
To: Toby Inkster <tai@g5n.co.uk>
Hey Toby,

I understand your concerns. Very strictly speaking one could say, however, that the processor graph becomes a conceptual entity as soon as your processor is categorized as a "SAX-based processor", to use the terminology in 7.6.1

http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#accessing-the-processor-graph

because what it says that you have to provide call-backs to access the error triples. How you implement that call backs is the implementation issue, and they can 'mimic' the triples internally by whatever they want.

That being said, I do not believe this issue merits a very complex discussion. If you think that a change is really necessary, this is what I propose to do (referring to the editor's version of the document[1]:

Section 4.1 now says:
---------------------
"The processor graph term is used to denote the collection of all informational, warning, and error triples that are generated by the RDFa Processor as a result of processing the document."
->
"The processor graph term is used to denote the collection of all informational, warning, and error triples that may used by the RDFa Processor to <a href="#processor-status">report is status</a>."

Section 7.6
-----------
"The processor graph is designed as a mechanism to capture all informational, warning, and error messages as triples from the RDFa Processor. "
->
"The processor graph is designed as an optional mechanism to capture all informational, warning, and error messages as triples from the RDFa Processor. "

If you agree with these changes I will commit the source and declare victory on that one!

Ivan



[1] http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html


On Feb 4, 2011, at 13:52 , Toby Inkster wrote:

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


----
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 Friday, 4 February 2011 13:45:30 UTC

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