Re: editorial informal comments on editor's draft

On Tue, 2007-03-27 at 11:42 +0100, Jeremy Carroll wrote:
> 
> The following editorial comments still stand, with the LC WD:
> 
> http://www.w3.org/TR/2007/WD-grddl-20070302/
[...]
> 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.
> ]]

I salted that a bit and added this to section 9 (#grddlvocab):

---8<---
In the section on Using GRDDL with XML Namespace Documents, only
explicit grddl:namespaceTransformation triples satisfy the premise of
the rule. Likewise, grddl:profileTransformation triples must be explicit
in the GRDDL result of a profile document in order to satisfy the
premise of the rule in the section on and on GRDDL for HTML Profiles.
Authors of GRDDL source documents are advised against using RDFS or OWL
expressions which imply such triples but do not explicitly state them.
---8<---


> > 2) normative refs
> > 
> 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>/

Yes, those are all straightforward; done.
http://www.w3.org/2004/01/rdxh/spec Revision 1.243

> > 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 ...)

yes; nice. done in 1.244.

> > 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.
> > ]]

I phrased it as...

---8<---
The rule above covers the case of a transformation property that relates
an XPath document node to an RDF graph via an RDF/XML document.
Transformations may use other, unspecified, mechanisms. For example, see
test #atomttl1, in which the the media-type attribute of the xsl:output
element bears a "text/rdf+n3" value to indicate a media type other than
"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.
---8<---

 
> > 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:
> ]]

I changed it to...

---8<---
The figure below shows the source document, the dc-extract.xsl
transformation, and the GRDDL result:
---8<---

and changed the paragraph before it, which was using obsolete
"meaning of the document" terminology;
it now uses "faithful rendition":

---8<---
For example, this document follows the conventions of [RFC2731], and it
explicitly uses the GRDDL profile and links to an XSLT transformation to
in RDF/XML to signal that the transformation is a faithful rendition:
---8<---


> 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

yes; that's a critical role that it currently plays...

> > 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.

I concerned about the impact that this edit would have. I'm
not inclined to make it at this point. Perhaps I'll discuss
it with the WG further.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 6 April 2007 04:38:24 UTC