W3C home > Mailing lists > Public > public-grddl-comments@w3.org > January to March 2007

Re: editorial informal comments on editor's draft

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Tue, 27 Mar 2007 11:42:32 +0100
Message-ID: <4608F518.3080304@hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:42 GMT