Re: Need for error messages?

Hi Ivan,

One minor modification of what you suggest would be to have a 'status'
graph that is emptied at the beginning of parsing. That way we don't
clutter up the default graph, and if at the end of parsing the status
graph is empty, all is well.

A different approach to using triples to communicate with a host
application would be for the parser to generate events. Then a
programmer could register handlers for those events and decide what to
do.

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.

Regards,

Mark

On Fri, Apr 30, 2010 at 2:22 AM, Ivan Herman <ivan@w3.org> wrote:
> Jeni's latest comments on @profile[1] reminded me of something I had already in mind. Jeni raises a number of issues around @profile files that were also discussed on the group (see Toby's earlier comments), but she does raise an interesting alternative, too. Namely, that if a @profile file is not accessible than no triples should be generated in the corresponding subtree.
>
> Regardless on whether we accept this proposal or not (I think it is an interesting avenue to explore) I wonder whether we should not introduce an error reporting mechanism into the RDFa processing in general. My approach would be as follows:
>
> - in specific cases the spec would define error conditions with error codes
> - errors are put into the output RDF graph of the processor, using something like
>
> [] a rdfa:error ;
>   rdfa:error_code "XXX"^^xsd:integer ;
>   rdfa:onURI <URI> ;
>   rdfs:comment "some additional comment set by the processor" .
>
> The specification would contain the error codes ("XXX" above), the additional comment text is left to the discretion of the RDFa processor.
>
> I can think of two situations from the top of my head where error codes would be welcome:
>
> - If the document itself is not accessible
> - If a particular profile file is not accessible
>
> In both cases the rdfa:onURI would refer to the problematic document.
>
> Additionally, I could also imagine to have an rdfa:warning type, whose content is left to the implementation (a typical example for warning may be if the URI resolution leads to an unusual URI scheme, ie, non of the http, mailto, ftp, etc, which may be the result of a missing prefix declaration that is interpreted as a URI.)
>
> Obviously, this is fairly easy to add to any processor. The result is part of the output graph, ie, clients may decide to take into account or ignore those triples easily. (My RDFa distiller actually implements this already, though not with formal error codes and not for missing @profile.)
>
> Thoughts?
>
> Ivan
>
> [1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Apr/0189.html
>
> ----
> 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, 30 April 2010 08:35:03 UTC