- From: Toby Inkster <tai@g5n.co.uk>
- Date: Fri, 04 Feb 2011 12:52:16 +0000
- To: Ivan Herman <ivan@w3.org>
- Cc: W3C RDFa WG <public-rdfa-wg@w3.org>
On Wed, 2011-02-02 at 11:42 +0100, Ivan Herman wrote: > Toby, does not this address your concern? Not especially. There are environments where a processor can be sure that the processor graph will never be needed. For example, it's a component in a larger piece of software, and that software's design is such that it will never need or request the processor graph. According to the spec, it still needs to have code that generates these triples, even if they'll never be used? The fact that some processors will have a processor graph and some will not is an interoperability concern, yes. But the question is, is it a big enough concern that we should add extra normative statements to the specification? I say no. If I'm writing an application and need to swap the RDFa library I'm using with a different one, it's unlikely that whether they both support a processor graph will be at the top of my concerns. Number one would probably be whether or not the new library is in the same programming language as the first - because using a library written in X from an application written in Y is usually not trivial. The paradigm it uses for retrieving data will be another concern - does it fire off a callback function for each triple encountered, or does it wait until the end and provide me with a single graph object as the result? If the latter, what are the methods by which I can inspect and manipulate the graph object? And so on. If swapping between libraries, whether they both support the processor graph feature might be a single concern out of a long list. But assuming we need to be concerned at all by the items on that list, they're really API concerns, not Core concerns. While it's plainly clear that setting minimum standards for what a processor graph must contain will be a great boon for interoperability, I really do not see what we gain by making the processor graph required. Leave it optional. People who are writing general purpose RDFa processing libraries will probably want to implement this feature. (I plan on doing so.) But those people who are writing more specialist RDFa processors and know they won't need it, why should we say that they're not compliant? If I just want to write an app that finds dc:license/cc:license/xhv:license triples and stores them in a big table like this: document | license --------------------------+------------------------ http://example.com/ | FDL 2.0 Then why do I need to generate a processor graph? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Friday, 4 February 2011 12:53:04 UTC