Re: ISSUE-26: RDFa-specific vs. Earl-like Processor Status vocabulary

Toby,

Without going into the technical issues here, can we try to separate two sub-issues and handling them separately? We are (again...) getting into a raging long email thread where, at the end, we will all loose because we will simply loose track.

There seems to be two sub-issues within issue-26:

1. Do we define the 'processor graph' mechanism as part of the RDFa Core (we are _not_ discussing the API).
2. What would an RDF error vocabulary for RDFa processing look like.

There is a Working group resolution on #1, which said 'yes'. Toby, your mail aims at reopening that resolution. It is up to Manu and Ben whether they want to do that or not. The only new argument/proposal I saw in your mail is to keep the current 'processor graph' mechanism as defined, but making it optional for a processor. That can be discussed separately.

This email thread was meant to close the sub-issue #2 which started based on a positive resolution of sub-issue #1. Can we, at least, close that one?

Sorry to be formal, Toby, it is certainly not my intention of avoiding discussions, but I am concerned about the lack of progress...

Cheers

Ivan

On Jul 8, 2010, at 02:48 , Toby Inkster wrote:

> On Wed, 7 Jul 2010 18:31:48 +0200
> Ivan Herman <ivan@w3.org> wrote:
> 
>> I am sorry Toby I do not understand. We have a decision that errors
>> should be added to a processor graph. Does it mean that you are
>> against that resolution altogether?
> 
> Indeed. I've never been in favour of it. It's simply a bad idea to
> *require* RDFa processors to build a graph of errors in order to be
> conforming.
> 
> Case: Alice is building a search engine to index the web and allow
> people to search for content by license. She's only interested in
> triples of the form { ?item xhv:license ?license . }. Why must she
> generate error triples if she knows they're never going to be queried
> (as the error vocab doesn't use the xhv:license predicate)?
> 
> I'm not saying that there should not be a vocabulary for describing
> errors found in RDFa documents - I'm just saying that processors should
> not be required to build an error graph.
> 
> What's the harm in making this optional? If I'm wrong and everyone else
> is right, then there'll be such massive consumer demand for this
> feature that all processors will implement it. But I really think this
> will turn out to be quite a niche feature.
> 
>> As for no other RDF serializations doing something similar: that is
>> true. But, although we do say that RDFa is yet another serialization,
>> the fact is that it does require a more complex processor than, say,
>> an RDF/XML or a Turtle parser. In this sense I am not sure the
>> comparison is fair...
> 
> I don't see how the complexity of writing a parser comes into it. (And
> RDF/XML is hardly simple!) It's more the issue is that from what I can
> see, it simply doesn't seem useful for most people.
> 
> I'll note here that not only do I not know of another RDF serialisation
> that makes requirements on processors as to how they report errors, but
> I don't know of any specification for a data format that makes such
> requirements. Even XML, which is pretty rigid on when errors need to be
> reported, doesn't mandate the mechanism by which they're reported.
> 
> Shane wrote:
> 
>> Do you have an alternative plan for dealing with errors during 
>> processing?
> 
> Yes - just let processors deal with it however they like; which will
> probably be in a manner appropriate for their environment. e.g.
> command-line clients might write to STDERR; Visual Basic libraries may
> prefer to raise resumable errors; XSLT scripts might insert XML comments
> into their output to note errors; browser-based RDFa processors might
> write to the browser's error console.
> 
> In particular, if you're implementing RDFa parser for an RDF toolkit
> that already contains other parsers, I'd expect that RDFa should use
> the same error handling mechanism that the rest of the parsers do.
> 
> By all means, add error handling to the RDFa API, but it just doesn't
> need to be in RDFa Core.
> 
> See also Mark's e-mail
> http://www.w3.org/mid/AANLkTinVaASo26g4Sls5Gtxrt333EtUp491RQVMqJf9A@mail.gmail.com
> 
> -- 
> 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