- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Tue, 27 Mar 2007 11:42:32 +0100
- To: Jeremy Carroll <jjc@hpl.hp.com>
- CC: public-grddl-comments@w3.org
The following editorial comments still stand, with the LC WD: http://www.w3.org/TR/2007/WD-grddl-20070302/ I have deleted some of my earlier comments, when I cannot suggest simple changes. The hope is that each comment suggests a simple edit, that the editor can simply OK (or not). I am happy to produce a copy of the editor's draft with any such edits applied. The only complex one concerns comment 8 on the mechanical rules. Jeremy Jeremy Carroll wrote: > 1) semantics > > > Possible clarifications fo the relationship to GRDDL and RDF-MT are: > > a) clarify that when looking for > grrdl:profileTransformation > and > grrdl:namespaceTransformation > only simple entailment is considered. > Such clarification could be accompanied by a > suggestion that profile and namespace authors should > avoid documents that RDFS or OWL entail such triples > unless the triples are made explicit. Some test cases > of such documents with empty GRDDL results would further > clarify. e.g. at end of section 9 add [[ The semantics of grddl:namespaceTransformation, grddl:profileTransformation grddl:transformation and grddl:transformationProperty are realized operationally during GRDDL processing. Since only simple entailment is used during such processing, authors of Semantic Web documents are advised against using RDFS or OWL expressions in which such properties follow under the RDFS or OWL semantics but are not explicit. ]] > > 2) normative refs > > I think it is good practice if each and every normative ref > is referenced by normative text. This is not the case > in this document. I suggest the editor review the normative refs > and either move some to informative, or add at least one reference > to each ref in the normative material. Suggestions Clarify first normative box in section 2 with s/base IRI/base IRI <a class="norm" href="#RFC3987">[RFC3987]</a> / Clarify second normative box in section 2 with s/RDF Graph/RDF Graph <a class="norm" href="#RDFC04">[RDFC04]</a>/ Clarify first normative box in section 4 with s/XHTML family/XHTML family <a class="norm" href="#XHTML">[XHTML]</a> Clarify second normative box in section 4 with s/the <tt>profile</tt> attribute/the <tt>profile</tt> attribute <a class="norm" href="#HTML4">[HTML4]</a>/ > > 4) space separated > > The term space separated is used every so often in the normative > text. The mechnical rules clarify this as "[ \t\r\n]+". > I suggest, that, at least once, this is clarified in the normative > text (particularly given the wide range of space characters in unicode) Add to the first normative box in section 2 the following para [[ <dfn>Space-separated tokens</dfn> are the maximal non-empty subsequences not containing the whitespace characters #x9, #xA, #xD or #x20. ]] (Nice declarative statement! Deals with leading and trailing space, repeated whitespace, empty strings ...) > 6) clarifying use of turtle/N3 > > The test testlist1#atomttl1 is only referred to in > the issue list appendix. > > I think it would be better to have a paragraph, maybe as a second para > in section 6 > along the lines of > [[ > The transformation property relates the XPath document nodes > to an RDF graph. These need not use RDF/XML as an intermediate > stage. To give an XSLT example, see testlist1#atomttl1, in which > the attribute-value media-type="text/rdf+n3" on the xsl:output > element indicates a different media type, from the default > value, within GRDDL, of "application/rdf+xml". GRDDL agents > that can process such a media type, can then produce an RDF graph > in accordance with the media type. Non-XSLT transforms may > indicate the RDF graph in some other, unspecified, fashion. > ]] > > 7) arrow labelled "info" > > In section 4, I read > [[ > In the figure below, the arrow labelled info relates a document > to an abstract notion of the information contained in the document. > ]] > > There is no such arrow. I suggest that the following old text be replaced by following new text: OLD [[ In the figure below, the arrow labelled info relates a document to an abstract notion of the information contained in the document. It shows that the RDF data extracted via the dc-extract.xsl transformation is part of the information contained in the document: ]] NEW [[ The figure below shows that the RDF data extracted via the dc-extract.xsl transformation is part of the information contained in the document: ]] Rationale: the arrow that might have been labelled info appears in many of the other diagrams without a label. Hence it would be inconsistent to label it in this case only, and too much work to systematically relabel. > > > 8) mechanical rules of doubtful value > > I think the mechanical rules serve the following valuable functions: > > a) to allow the editor to satisfy himself that the normative text > is appropriate > b) to illustrate a simple implementation of GRDDL (except the security > considerations) > > I do not believe that either of these functions justifies the > prominence given to the rules in the spec. I think it would be > better to move the mechanical rules to an appendix; while > maintaining the strong link between each rule and the normative > text that it implements. For instance the appendix could consist of all the current normative boxes + mechanical rules, (repeating the normative text). This would probably be the minimum edit to positively address this comment if the editor/WG are so minded. Jeremy Carroll -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Received on Tuesday, 27 March 2007 10:42:52 UTC