- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Mon, 04 Dec 2006 11:57:39 +0000
- To: public-grddl-comments@w3.org
Hi Brian is encouraging me to think about implementing GRDDL within Jena. I started by reading the three drafts, and also looked at the editor's draft of the main document. http://www.w3.org/TR/2006/WD-grddl-20061024/ http://www.w3.org/TR/2006/WD-grddl-primer-20061002/ http://www.w3.org/TR/2006/WD-grddl-scenarios-20061002/ http://www.w3.org/2004/01/rdxh/spec I have not done a detailed review; I could do one now if that would be helpful to the group, but I suspect it would help more if I held off until either the next publication, or until Last Call. However I had three immediate comments. Editorial (praise): ================== I found the following line in the introductory example highly enlightening: <foaf:isPrimaryTopicOf rdf:resource="http://en.wikipedia.org/wiki/Stephen_King" /> A, somewhat philosophical, issue, that has caused problems to semantic web recommendations in the past, is how to relate the formal semantics with the real world. I felt that the pointing to the Web that this line involves seems to illustrate some of the ideas of "Clients reading the document can follow their nose " (Primer abstract) It also seems to illustrate aspects of "Faithful Renditions", which perhaps could be made clearer. Typically a faithful rendition will involve reference to Web resources which may change under the authors feet, and the "faithful rendition" is intended as a best effort, such as we typically make when trying to communicate, and isn't going to be entirely bullet proof. Feedback ======== Between "Using GRDDL with an RDF Namespace document" and "Using GRDDL with an XML Schema namespace document" there is the comment: [[ The Working Group is likely to add a section to the GRDDL primer much like this subsection. Since this subsection has no novel normative material, we're interested in feedback on whether it should remain part of this specification once it is covered by the primer. ]] My own view is that if an example is appropriate for the primer then it should be there and not in the specification; however, more complex cases, may be usefully illustrated for the developer within (an informative) subsection of the specification. In particular, in the XML Schema case, I understand that multiple GRDDL transformations have to be used. This seems like an example of appropriate complexity for the spec, with perhaps a simplification in the primer that glosses over some of the mechanics. Related editorial comments ========================== If I have understood the text correctly then http://www.w3.org/2004/01/rdxh/figGleanPO.svg would be clearer if the arrow lablled namespaceTransformation was directed from the lower "result RDF" box rather than from the "po-ex" box. i.e. the client first applies the embeddedRDF.xsl transform, can then read the result to find the RDF indicating the grokPO.xsl transform. Also "grok" is not a commonly understood word (although I like and use it frequently!). Suggest changing "grokPO.xsl" to "understandPO.xsl" Substantive XSLT 2.0 ==================== I was very surprised to see that this spec referred to XSLT 1.0 and not XSLT 2.0. By the time GRDDL goes to rec, XSLT 2.0 is likely to be the W3C recommendation, and I don't see why the GRDDL WG should recommend a solution that the consortium has significantly improved. In particular, browser support seems to be a) irrelevant for many uses (are browsers going to be the main GRDDL engines, I think not) b) historically dated, browser support for XSLT 2.0 is likely in the future. Also the minutes of the 30 Aug meeting do not seem to reveal why MUST in the e-mail message became SHOULD. While it is clear that some software may use a GRDDL mechanism for say processing javascript, and not support XSLT, I think it is clearer to say that these are not GRDDL clients. i.e. [[ A GRDDL client MUST support XSLT 2.0 and XSLT 1.0 Authors of GRDDL documents are advised that restricting themselves to XSLT 1.0 may achieve higher interoperability with clients that partially implement the GRDDL specification. ]] The WG appears to want GRDDL to be an open-ended mechanism for experimenting with different transformation languages. I have nothing against that, but the recommendation should concentrate on a realistic interoperable solution; and the WG should ensure that a client implementing the specification can appropriately flag any more experimental use of GRDDL that it does not support. Jeremy
Received on Monday, 4 December 2006 11:58:15 UTC