- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 05 Sep 2006 10:54:01 -0500
- To: Harry Halpin <hhalpin@ibiblio.org>
- Cc: Ian Davis <ian.davis@talis.com>, public-grddl-wg@w3.org
On Tue, 2006-09-05 at 16:22 +0100, Harry Halpin wrote: > Logically, since a client may only understand some of the transformation > languages, we can't require any "GRDDL-aware client" to run all the > transforms. It can't run a transform in a language it doesn't > understand, and so different clients will get possibly different RDF > out of the same document even if we require them to "run all the transform" > > However, I do think we should clarify that either the client should either: > > 1) If it can run a transforms, it runs the transform. > > 2) Or if can run a transform, the client may or may not run the transform. I think the spec already says 2) clearly enough. I think introducing conformance labels like "GRDDL client" is much more trouble than it's worth. I think specifying the meaning of documents and publishing examples and test cases is sufficient (as well as necessary). Given the security issues around running code published in the Web, which transformations to run clearly must be left up to local policy, no? Consider an agent that has a hard-coded list of profile and/or transformation URIs; its policy is to execute those transformations and no others. For example, a big data aggregator (think: yahoo local, ...) might publish a list of 20 profiles and transformations (hCard, eRDF, ...) and offer to aggregate data that uses those profiles. They might add new ones over time, after carefully reviewing and caching the published XSLT implementation, or by re-implementing the transformation in C locally. Is anybody interested to make a test case to illustrate that case? I think the current test cases all involve a graph matching test; perhaps another class of tests would involve subgraph matching. i.e. the results are correct as long as they're a subgraph of the expected results. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Tuesday, 5 September 2006 15:54:20 UTC