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

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>