- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Mon, 23 Apr 2007 14:36:29 +0100
- To: Jeremy Carroll <jjc@hpl.hp.com>
- CC: public-grddl-comments@w3.org
All these comments have been addressed to my satisfaction in the current editor's draft: http://www.w3.org/2004/01/rdxh/spec $Date: 2007/04/18 14:54:08 $ $Revision: 1.250 $ Jeremy Jeremy Carroll wrote: > > 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 Monday, 23 April 2007 13:36:58 UTC