editorial informal comments on editor's draft

While reviewing
  2007/02/21 16:25:45 number 1.228

I also noted the following editorial points.

These comments probably should be addressed at some point, but are
not critical (IMO) for last call.

Assuming the WG move to last call soon, I will follow-up on this message 
after LC publication and indicate which comments have been addressed and 
which might merit further thought.

I am not expecting any WG action on these comments before last call, but 
obviously would be pleased to the extent that the WG and editor have 
time to address any.

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.

b) permit a GRDDL agent to make a lean version of
a (merged set of) GRDDL results


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.

In particular I ask the editor to double check that the XHTML ref
is the one intended. It surprised me, but I am aware that the
editor is much better versed in HTML technologies than I am.

3) stability of embeddedRDF.xsl

An example in section 3 uses:

data-view:transformation="http://www.w3.org/2003/g/embeddedRDF.xsl"

I note that this implies that the transform is an implicit deliverable
of the WG, and there is an implicit commitment to maintain the stability
of the transform.


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)
5) rel="profileTransformation"

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


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 stong link between each rule and the normative
text that it implements.

9) use of word 'grok' in example URIs
e.g. grokPO.xsl

I like the word 'grok' a lot, and use it frequently.
It is very often not grokked by my conversation partners,
particularly when they are not of a geek-like leaning.
I suggest using a more widely known word like 'transform'.

10) profileTransformation

Despite my earlier comments concerning
http://www.w3.org/2003/g/glean-profile

I felt that the example in
http://www.w3.org/TR/2006/WD-grddl-20061024/
shows a useful idiom for writing profile documents in HTML.


<head profile="http://www.w3.org/2003/g/data-view">
<link rel="transformation"
     href="http://www.w3.org/2003/g/glean-profile" />
...
<p>This is a profile transformation link:
<a rel="profileTransformation"
 
href="http://example.org/BIZ/calendar/extract-rdf.xsl">extract-rdf.xsl</a>


If the WG has the resources, I suggest including
http://www.w3.org/2003/g/glean-profile
in the implicit deliverables, and including the example
from the previous WD, either in the LC WD, or in the primer.
However, to do so would entail some clean-up of
http://www.w3.org/2003/g/glean-profile

Received on Wednesday, 28 February 2007 09:30:01 UTC