PROPOSAL to close ISSUE-53: DataParser Interface

If there are no objections to this proposal in 7 days, we will close
ISSUE-53: DataParser Interface and Arguments Upgrades.

http://www.w3.org/2010/02/rdfa/track/issues/53

The set of changes proposed primarily addressed the use of the RDFa in
low-memory environments as well as making the process() and parse()
methods more orthogonal to one another. Specifically, the changes allow
triples to be processed as a stream instead of as a complete collection
of triples and allow the use of the Data Parser in synchronous and
asynchronous modes. The process() interface could be of use on embedded
devices as loading in thousands of triples may not be possible on
low-memory devices.

The DataParser interface was moved from the RDFa API to the RDF API:

http://www.w3.org/2010/02/rdfa/sources/rdf-api/#data-parsers

The following changes have been made to the specification based on the
comments provided by Nathan:

> DataParser.parse gains an optional filter which allows only triples
> matching a given filter to be added to the store.

Done.

> DataParser.parse has it's argument swapped around to align with
> process and to promote async usage.

Done.

> Setting the second param to a ParserCallback (below) ensures the API
> is async by default, if no graph is passed in (as fourth param) then
> a new graph/store is created, if "x" is provided and callback is null
> then API flips in to sync mode (after parsing the completed
> graph/store is populated with triples from default graph).

Done.

> DataParser.process is added which rather than adding triples to a
> store, executes a given callback on each triple, thus allowing say
> all telephone numbers in a document to be highlighted without storing
> any data / increasing memory usage, this method also has the optional
> `filter` property functioning the same as that on DataParser.parse.

Done.

> DataParser gains a constructor parameter which accepts a DataContext,
> as parsers require access to TypedLiteral conversion functions, and
> to the create*** methods.

Done, although I question the Constructor decorator as it pollutes the
global namespace. We could get away with a factory method - which has
its own issues, but the concern isn't strong enough to not resolve this
issue. Another issue on the use of a Constructor on the DataParser
interface could be raised at a later date.

> A new DataProcessor Callback interface is added with only one
> parameter, triple (to keep things light).

This was changed to a TripleCallback interface to bring it in-line with
the rest of the API and simplify the number of interfaces that are
needed by the RDF API.

> A new ParserCallback (name tbd) Callback interface is added with only
> one parameter, which will be RDFGraph or DataStore.

Done. The argument is a Graph.

The proposal is to accept the changes made to the DataParser interface.

Please comment in 7 days from this post if you object to this proposal.
If there are no objections within 7 days, ISSUE-53 will be closed.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Linked Data in JSON
http://digitalbazaar.com/2010/10/30/json-ld/

Received on Sunday, 2 January 2011 19:55:58 UTC