Draft comments on cc/pp last call WD

I have partially reviewed the CC/PP last call WD:

   http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030325/

and propose the following comments for consideration by the RDFCore WG.

1. RDFCore considers all of these comments to be editorial and does not 
expect that any changes made in consequence will result in another last call.

2.  RDFCore is pleased by the replacement of the tutorial on RDF with a 
reference to the tutorial being developed by RDFCore.  It notes that 
CC/PP's normative references are to RDF M&S and the candidate rec RDF 
Schema.  We suggest that CC/PP update the normative references to refer to 
the RDFCore last call WD's.  Should the CC/PP WG prefer not to change these 
references, we suggest a brief note informing the reader that primer 
describes a more recent revision of RDF specs.

3. Section 4.1.1.1 Values described by URIs

[[A common requirement is to identify some resource using a URI as the 
value of a CC/PP attribute (e.g. a device type or an applicable DTD or schema).

In such cases, the attribute value is represented as an RDF resource having 
the designated URI. In RDF/XML, this may be represented as an 
<rdf:Description> element in a property element, or an rdf:resource XML 
attribute of a property element; e.g. ...]]

In the example given the value of the RDF property is the resource 
identified by the given URI, not the URI used to identify it.

We suggest:

[[A common requirement is that the value of a CC/PP attribute is some 
resource identified by a URI Reference, e.g. a device type or an applicable 
DTD or schema.   In RDF/XML, this may be represented as an 
<rdf:Description> element in a property element, or an rdf:resource XML 
attribute of a property element; e.g. ...]]

4. Section 4.1.1.2 Text values

[[A text value is a string that is used to describe or identify some 
specific CC/PP attribute value.]]

We find the language here confusing.  It seems to say that the CC/PP 
attribute value is a different thing (that is described or identified by) 
the text value.  Yet in 4.1 it states:

[[All CC/PP attributes should be defined with values that can be treated as 
one of the simple or complex data types discussed later.]]

which suggests that the text value and CC/PP attribute value are the same 
thing.

We suggest that the specification be modified to describe the following 
concepts:

  o the lexical space
  o the RDF Literal value space
  o XML Schema value space
  o the CC/PP Application value space

CC/PP is using RDF plain literals to represent datatype values.  Whilst RDF 
does not treat plain literals as a datatype, CC/PP may consider the value 
space of RDF plain literals to be either a sequence of characters if no 
xml:lang is in scope, or a pair of a sequence of characters and a lang tag 
if an xml:lang is in scope.

We suggest that the CC/PP spec should define the mapping from the RDF value 
space to the CC/PP Application value space for the CC/PP value types text, 
integer and rational.  It should specify whitespace processing and what to 
do with the lang tag (ignore it?) if present.

We suggest that the text be modified, especially in the use of the term 
'value', to be clear about which value space is being referred to.

5. Section 4

There are several phrases in this section of the form "?datetype values are 
based on ...".  The specification should be more precise, e.g., for an 
CC/PP integer value:

  o the string part of the RDF literal must be a member of the lexical 
space of xsd:int.
  o the value is the integer that xsd:int maps that string to

6. Section 4.1.1.4

[[o 1/2 -- this is equivalent to decimal 0.5]]

This may be potentially troublesome in the future.  It makes a statement 
about the CC/PP Application value spaces that could contradict a future 
fully defined rational datatype defined by XML Schema.  It would be better 
simply to omit the statement of equivalence.

7. Section 4.1.1.4

The regular expression defining the lexical form isn't quite right.  It 
doesn't allow a leading + or -.

8. Section 4.2

[[are combined to yield the attribute name URI:

http://www.w3.org/2002/11/08-ccpp-client#type

]]

That's not a URI, its a URI Reference.

9. Section 4.3

[[Appendix B to this document contains an RDF schema with which all CC/PP 
profiles must conform, and Appendix C contains an example of a vocabulary 
definition schema.]]

RDF defines no notion of conformance to a schema, nor does it really define 
vocabularies.  Suggest:

[[Appendix B to this document contains an RDF schema describing terms for 
use in CC/PP profiles.  Appendix C contains an example Schema describing a 
CC/PP vocabulary.]]

10. Appendix B.3

[[

   <rdfs:Class rdf:about='&ns-ccpp;integer'>
     <rdfs:label xml:lang="en">Integer value</rdfs:label>
     <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
     <rdfs:comment xml:lang="en">
       This class defines the CC/PP integer data type.
     </rdfs:comment>
     <rdfs:seeAlso rdf:resource=
         'http://www.w3.org/TR/xmlschema-2/#integer'/>
   </rdfs:Class>
]]

We have a number of concerns about the rdfs:comment:

   o the class does not 'define' anything.
   o datatypes in RDF, which CC/PP is not using yet, but may in the future, 
are not classes - they follow the XML Schema datatyping model, having a 
lexical space, a value space, a mapping etc.
   o there is a confusion between the RDF literal representing the value 
and CC/PP application value itself

We suggest this comment (and others similar) be rephrased as:

[[This is the class of RDF Literals that represent CC/PP Application 
integer values.]]

This phrase has been chosen to permit the use of the RDF datatype machinery 
at a future date.

11. Appendix B.3

We note that a ccpp:anyURI is defined in the schema, but not mentioned in 
section 4.

12. Appendix B.3

We note that the appendix contains no description of CC/PP tokens, 
described in section 4.

Received on Monday, 31 March 2003 09:00:11 UTC