ISSUE 26: Proposal for RDFa Core/API Error Reporting Mechanism

Hi folks,

I wanted to pass this by the mailing list to get feedback/objections
regarding the new RDFa error reporting mechanism before I started
authoring draft language for both the RDFa Core document and the RDFa
API document. The working group will discuss this proposal at the next
telecon.

RDFa Core - Error Reporting Mechanism
-------------------------------------

Traditionally, the RDFa Processor has been concerned about generating
triples for a single graph, called the default graph.

As we move forward with an error reporting mechanism, an RDFa Processor
would be concerned about generating triples for two distinct graphs: the
default graph, and the processor graph.

All triples in the processor graph are related to RDFa
Processor-generated information, warnings, and errors.

A developer may access either graph, or both graphs by providing
arguments to the RDFa Processor.

If the RDFa Processor is a SAX or Event-based processor that generates
triples, the developer may provide a separate callback function for
default graph triple generation and processor graph triple generation. A
SAX-based RDFa Processor SHOULD provide a mechanism to optionally
capture either stream of triples.

If the RDFa Processor produces an RDF graph in RDF/XML, Turtle, N3,
N-Triples, or a similar all-in-one graph mechanism, the developer may
provide an argument to the parsing method that specifies: "default",
"processor", or a comma-separated list combining both graphs
"default,processor". An RDFa Processor that produces an RDF graph as
output SHOULD provide a mechanism to optionally retrieve either graph
individually, or both in a combined manner.

If the RDFa Processor produces an RDF graph via a Web Service call, the
graph can be selected by specifying an item in the query parameter
string in the URL. For example:
   http://example.org/parse?graph="default,processor"
An RDFa Processor that is exposed via a Web Service SHOULD provide a
"graph" query parameter that takes all of the values specified in this
section ("default", "processor", "default,processor", "processor,default").

RDFa API - Error Reporting Mechanism
-------------------------------------

The RDFa API currently contains no error reporting mechanism. Several
people in the RDFa community have been asking for an event-based error
reporting mechanism.

We may want to add two mechanisms to the RDFa API - an Event-based
mechanism, and a graph-based mechanism for discovering informational
messages, warnings and errors generated by the RDFa Processor.

The event-based mechanism would hang off of the Data Parser interface:

boolean parse (in Element domElement, in Callback processorCallback);

processorCallback is called whenever any triple that is considered to be
a member of the processor graph in RDFa Core is generated. The callback
takes three arguments, a subject, predicate and object.

The model-based mechanism would require the registration of an optional
DataStore for the processor graph as defined by the RDFa Core specification.

var parser = document.data.createParser("rdfa1.0", defaultStore,
                                        processorStore);

The optional processorStore argument would associate an additional
DataStore to store all triples in the processor graph as defined by RDFa
Core. The createParser interface on DocumentData would change to the
following:

DataParser  createParser (in DOMString type, in DataStore defaultStore,
                          in optional DataStore processorStore);

If processorStore is not specified, no processor graph triples will be
accessible via the created parser.

By default, the processor graph is accessible via a read/write attribute
on the DocumentData object:

readonly attribute DataStore processor;

By default, after a successful RDFa document processing run, the
"processor" DataStore contains the entire processor graph as defined by
the RDFa Core document.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Myth Busting Web Stacks - PHP is Faster Than You Think
http://blog.digitalbazaar.com/2010/06/12/myth-busting-php/2/

Received on Monday, 28 June 2010 05:08:34 UTC