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

[CLOSED] Re: editorial informal comments on editor's draft

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Mon, 23 Apr 2007 14:36:29 +0100
Message-ID: <462CB65D.9090801@hpl.hp.com>
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 GMT

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