- From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
- Date: Tue, 5 Sep 2006 12:35:14 -0400 (EDT)
- To: public-grddl-wg@w3.org
On Tue, 5 Sep 2006, Harry Halpin wrote: > Here's a use-case: Thanks.. > > Say there's a web-page marked up with hCals and hCards, and so has > transformations in XSLT 1.0 for both to RDF vocabularies. The client is > only interested in events, not in people's contact details. So, does the > client: > > 1) Run both transforms, then merge the RDF graphs of the results. > > 2) Run only the relevant transform, i.e. hCal to RDF. I would think that if the publisher specifically referred to *both* an hCal and hCard transformation that it was his/her intent that the *combined* use of the RDF vocabularies preserved the meaning of his/her original web page. In which case, the client (unless there was some local policy against doing so - a policy that only hCal transformas would be run) would do 1) and cherry-pick (so to speak) only the terms it was interested in from the merged graph. Chimezie Ogbuji Lead Systems Analyst Thoracic and Cardiovascular Surgery Cleveland Clinic Foundation 9500 Euclid Avenue/ W26 Cleveland, Ohio 44195 Office: (216)444-8593 ogbujic@ccf.org > > > > Chimezie Ogbuji wrote: >> >> On Tue, 5 Sep 2006, Dan Connolly wrote: >> >>>> 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. >> >> 1> >>> I think introducing conformance labels like "GRDDL client" is >>> much more trouble than it's worth. >> >> Than is my action item regarding defining such labels a moot point? >> >>> 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? >> >> I'm not sure. I mean, I can see the security issues being a prime >> factor in having the 'client' decide which transformations to run, but >> assuming there were no issues with 'local' policy, I don't understand >> how you can claim the transformations (identified by the publisher) >> 'preserve' the author's meaning but leave it up to the client which >> transformations to run. >> >> Perhaps, a clear usecase as to the value of choosing to only run a >> subset (besides security considerations) would help me understand the >> value in this. Looking at the xml-stylesheet processing instruction >> specification, it doesn't seem to leave the matter up to the client. >> >> [[[ >> >> Multiple xml-stylesheet processing instructions are also allowed with >> exactly the same semantics as with LINK REL="stylesheet". >> >> ]]] >> >> I'm not aware of what is expectred of the client from a >> link/@rel='stylesheet' in an XHTML document (does it have the option >> to not apply the stylesheet?). >> >> >>> 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 might, mostly because I'm concerned that there is a conflict with >> claiming the transformation preserve the document's meaning (which is >> a vague statement in itself) and not mandating that all referred >> transformations should be run (barring local such policies) >> >> Chimezie Ogbuji >> Lead Systems Analyst >> Thoracic and Cardiovascular Surgery >> Cleveland Clinic Foundation >> 9500 Euclid Avenue/ W26 >> Cleveland, Ohio 44195 >> Office: (216)444-8593 >> ogbujic@ccf.org >> >> > > > -- > -harry > > Harry Halpin, University of Edinburgh > http://www.ibiblio.org/hhalpin 6B522426 >
Received on Tuesday, 5 September 2006 16:35:27 UTC