- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 02 Jan 2011 14:55:28 -0500
- To: RDFa WG <public-rdfa-wg@w3.org>
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