Re: Need for error messages?

On Apr 30, 2010, at 07:00 , Mark Birbeck wrote:

> Hi Ivan,
> 
>>> For example, an 'error-profile-not-available' event handler might
>>> choose to abort processing completely, whilst a
>>> 'warning-prefix-not-defined' handler might be used in only in an
>>> editing scenario, as a way to give authors some feedback as they work.
>>> 
>> 
>> The problem with this approach is that it does not properly work in a distiller setting. If I issue
>> a request to distill an RDFa content, I expect a graph back. Events is then a kind of an
>> out-of-bands mechanism that does not fit well into the model. That is why I really prefer to
>> base this on graphs...
> 
> I think what you want is still possible:
> 
> 1. Your distiller would be a wrapper around an RDFa parser.
> 
> 2. The parser would fire events at various points according to the
> spec -- parsing begins, parsing ends, profile loading started, profile
> loading completed, profile failed to load, prefix not found, and so
> on. (Events are something that I want to add to the RDFa DOM API
> anyway, and have discussed a little with Benjamin and Manu. But until
> I saw your suggestions, I had only been thinking of general things
> such as 'parsing complete'.)
> 
> 3. Your distiller would have event handlers registered on the parser,
> and the handlers would implement whatever you decide is the
> appropriate course of action: you might abort processing on an error,
> and return an error message; you might create your 'error graph' as
> you describe; if a profile fails to load you may decide to load a
> cached version, or try a completely different server, based on a
> lookup. And so on.

Yes, it can be done, but it would force me to make a fairly radical rewrite of what is already there...

But that may not be the point; I would survive:-). The issue is what users expect. I can see the point that a Javascript programmer may prefer events and call backs. Ie, for a Web Application that might be a good model. However, there is a large class of users that, eg, crawl web sites to extract RDF data encoded in RDFa files. They do not really care about the API. Yahoo indexing is a typical case; these all use some sort of an application like the distiller: "URI of a page in, graph out". What you are saying is that all those applications (and let us not forget that there are already quite some deployment out there...) may have to do some structural re-engineering like what you propose; I am not sure that is good to ask at this point.

Also: it would be fairly complex, in my view, to spec properly an event model into the RDFa Core document that would specify all that. Adding triples into a graph (whether the default or another 'status' graph) seems, on the other hand, a very easy thing to define and add.

Maybe the RDFa Core (which does not talk about an API) and the RDFa API document could look different in this respect; the RDF API may define a separate event set for possible errors (that are defined by RDFa Core)...

> 
> So I'm thinking that from the point of view of the specifications we
> should be considering providing hooks out of the parser, so that
> applications that use a parser can decide what they want to do with
> the knowledge that something has gone wrong (or right). By providing
> these hooks we allow for all sorts of courses of action, including the
> one that you describe.
> 

I am afraid of things becoming a bit too complicated here... But I may be (as usual:-) pessimistic...

Ivan


> Regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)


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