There are 9 comments (sorted by their types, and the section they are about).
question comments
Comment LC-1775
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: 2.1.2 Component attributes
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stéphane Boyera
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :The Note right before 2.1.2, right after Figure 2-1b refers to the
issues on the RDF/XML encoding and the restrictions thereof.
First of all, I presume the intention was to refer to he RDF/XML Syntax
specification and _not_ the RDFPrimer as said in the note. It already
appears among th normative references under the heading [RDFXML].
However, it is not clear to me whether a more 'crisp' statement is true
or not. Is it correct that the _only_ RDF/XML feature of RDF/XML that is
_not_ allowed in a CC/PP application is the typed node syntax (this is
the way I read the note)? Ie, am I allowed to write something like:
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware"
ex:displayWidth="320" ex:displayHeight="200">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
</rdf:Description>
</ccpp:component>
which is, in terms of RDF/XML, equivalent to:
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
</rdf:Description>
</ccpp:component>
If yes, I think it is worth stating this more clearly (as my sentence
above says). If not... well, then a more systematic list of what is
allowed and what is not allowed should be listed somewhere.
It is of course the decision of the Working Group in which direction the
decision is taken. As far as I am concerned, from an RDF point of view,
I would prefer to require a full acceptance of RDF/XML rather than
defining a subset. But I understand the constraints with UAProf. (I had
a quick look at the UAProf2 document that CC/PP refers to, but it is
also silent on the details of this, by the way)
Note that, strictly speaking, the current spec _violates_ this
restriction! Indeed, the idiom
<ex:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</ex:htmlVersionsSupported>
makes use of the type node feature of RDF/XML, ie, in case you maintain
this restriction on RDF/XML, then all your examples should be encoded by
<ex:htmlVersionsSupported>
<rdf:Description>
<rdf:type rdf:resource=".....Bag"/>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Description>
</ex:htmlVersionsSupported>
Related issues: (space separated ids)
WG Notes: First, it's a good catch about the reference. It should be to
RDFXML not RDFPRIMER. so the change has been added to the document
Second, the WG doesn't think the text makes the assertion that you states. The note doesn't say anything about CC/PP placing restrictions on the use of RDF. It says that if you want your CC/PP profile to be compliant with UAProf, you mustn't use typed nodes.
So the WG proposes making no change on this part.
Resolution: First, it's a good catch about the reference. It should be to
RDFXML not RDFPRIMER. so the change has been added to the document
Second, the WG doesn't think the text makes the assertion that you states. The note doesn't say anything about CC/PP placing restrictions on the use of RDF. It says that if you want your CC/PP profile to be compliant with UAProf, you mustn't use typed nodes.
So the WG proposes making no change on this part. (Please make sure the resolution is adapted for public consumption)
Comment LC-1772
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: 3.1 Components
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stéphane Boyera
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Section 3. CC/PP Structure, 3.1. Components, 1st paragraph says
"For compatibility with UAProf, the namespace used to qualify component
MAY be a UAProf namespace."
I do not understand this statement. Does it mean that you may have _two_
different "component" resources that one can use, one not defined by the
current document? This strikes me as wrong; they are the different
resources in RDF terms.
Maybe an extra statement should be put into ccpp-schema that binds these
two instead (eg, an rdfs:subclassOf in one direction or, if you accept
to use OWL statements, an owl:sameAs or something like that...)
Note that this entry appears in the conformance criteria, section 5.1,
item #9
Related issues: (space separated ids)
WG Notes: Again, here, from a purely RDF perspective you are completly right: there could be a way to integrate in the ccpp-schema the definition of the UAProf component through one of the ways you are mentionning.
That said, as it is explicitly said, in order to ensure compatibility with UAProf now, as it is defined today, it is essential to allow the use of the UAPRof component. In case, we would work with OMA on a next release of cc/pp 2, we would surely integrate this comment and make sure that only one component is defined. It's also worth noting that the wording in the new version of the spec is identical with that in the previous version of the spec which is a W3C recommendation and presumably was acceptable to everyone at the time. We're not seeking to change anything that was agreed in the first version apart from those changes that caused divergence from the ability to support UAProf
Resolution: Again, here, from a purely RDF perspective you are completly right: there could be a way to integrate in the ccpp-schema the definition of the UAProf component through one of the ways you are mentionning.
That said, as it is explicitly said, in order to ensure compatibility with UAProf now, as it is defined today, it is essential to allow the use of the UAPRof component. In case, we would work with OMA on a next release of cc/pp 2, we would surely integrate this comment and make sure that only one component is defined. It's also worth noting that the wording in the new version of the spec is identical with that in the previous version of the spec which is a W3C recommendation and presumably was acceptable to everyone at the time. We're not seeking to change anything that was agreed in the first version apart from those changes that caused divergence from the ability to support UAProf (Please make sure the resolution is adapted for public consumption)
Comment LC-1773
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: 3.3 Defaults
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stéphane Boyera
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Section 3. CC/PP Structure, 3.3, 3rdf paragraph says
"Defaults can be encoded inline or as separate documents referred to via
URI, but can not be encoded both inline and as a separate document."
I do not understand this requirement. From an RDF point of view there is
no difference between the two, as long as the URI of the default
component is identical (and the examples in the document show that!)
Note that this entry appears in the comformance criteria, section 5.1,
item #12
Related issues: (space separated ids)
WG Notes: The requirement is to prevent the usage, within a component, of both a link to an external default and an inline one. Some components in one profile may have an inline ccpp:defaults, some others may have a link to an external documents. The rational for not allowing both inline and external reference in one component is to prevent conflicting information, and to avoid having to define precedence, profile matching, and rules of conflict resolutions. Such complexity is not appropriate for describing ccpp:defaults.
Resolution: The requirement is to prevent the usage, within a component, of both a link to an external default and an inline one. Some components in one profile may have an inline ccpp:defaults, some others may have a link to an external documents. The rational for not allowing both inline and external reference in one component is to prevent conflicting information, and to avoid having to define precedence, profile matching, and rules of conflict resolutions. Such complexity is not appropriate for describing ccpp:defaults. (Please make sure the resolution is adapted for public consumption)
Comment LC-1774
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: 5.1 CC/PP Document Conformance
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stéphane Boyera
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :Conformance criteria, section 5.1
Entry #1 says
"The document MUST be valid RDF serialized in XML".
The introduction says that XML (ie, RDF/XML) is only one of the possible
serializations. I presume this entry should simply say
"The document MUST be valid RDF in some serialization format".
Also, Entry #2 seems to be a pretty meaningless requirement in the sense
that any serialization of RDF that is valid also means conformance to a
valid syntax to namespaces. That is _not_ a CC/PP requirement but simply
a valid RDF serialization requirement. The same holds for Entry #5: it
refers to the way a valid serialization handles URI-s. Nothing special
to CC/PP
Ivan
Related issues: (space separated ids)
WG Notes: accepted
Resolution: accepted (Please make sure the resolution is adapted for public consumption)
editorial comments
Comment LC-1770
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: Document as a whole
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :3. Overall in the document: the examples as well as the figures use,
sometimes, the rdf:li idiom of RDF/XML, while sometimes they use the
rdf:_1, rdf:_2 properties. From RDF/XML point of view these are both
o.k. and mean the same thing. The document is consistent in the sense
that if a figure uses, say, rdf:li, then so does the corresponding code.
However, I still wonder whether it is wise to mix the two idioms in this
document. (Examples: Figure 3-2c uses the rdf:_1,... idiom, whereas
Figure 2-2b uses the rdf:li approach.)
This was discussed before and, as far as I remember, the decision to
keep both in the document to show that this can be done and both are
valid. If this is the reason, it may worth stating this explicitly
somewhere and refer to 2.15 section of the RDF/XML spec
Related issues: (space separated ids)
WG Notes: This document has not the aim to present RDF/XML and the different options existing for the same meaning. We agree that the use of both annotations may confuse the reader, and decided to use rdf:li approach in the whole document
Resolution: This document has not the aim to present RDF/XML and the different options existing for the same meaning. We agree that the use of both annotations may confuse the reader, and decided to use rdf:li approach in the whole document (Please make sure the resolution is adapted for public consumption)
Comment LC-1768
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: Abstract
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stéphane Boyera
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :1. In the abstract, bulleted item on using RDF classes: to avoid
misunderstandings it may be worth saying "RDF Schema aware processors"
rather than "schema-aware RDF processor". There is a possibility of
confusion between RDF Schema and XML schema (unfortunately...)
Related issues: (space separated ids)
WG Notes: accepted
Resolution: accepted (Please make sure the resolution is adapted for public consumption)
Comment LC-1769
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: 1. Introduction
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
Not assigned
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :2. In the introduction, 3rd paragraph. The text refers to TURTLE as an
alternative serialization of RDF, which is fine. I wonder whether it
would be worth adding a reference to GRDDL, too. CC/PP strikes me as a
relatively simple vocabulary that could be written down as part of an
XHTML file with some sort of an agreed microformat or RDFa, and then
GRDDL-d to extract the RDF/XML information. (This is really just a
proposal, and no problem if the WG does not want to go down that road...)
Related issues: (space separated ids)
WG Notes: We can certainly add a link to GRDDL. That said we don't want to explore further the usage you are mentionning now. It may be worth thinking about it in a next release, but for now that would require further work, defering the release of the spec.
Resolution: We can certainly add a link to GRDDL. That said we don't want to explore further the usage you are mentionning now. It may be worth thinking about it in a next release, but for now that would require further work, defering the release of the spec. (Please make sure the resolution is adapted for public consumption)
Comment LC-1771
Commenter: Ivan Herman <ivan@w3.org> (archived message ) Context: 3.1 Components
Status: open
proposal
pending
resolved_yes
resolved_no
resolved_partial
other
assigned to Stéphane Boyera
Type: substantive
editorial
typo
question
general comment
undefined
Resolution status: Response drafted
Resolution implemented
Reply sent to commenter
Response status:
No response from Commenter yet
Commenter approved disposition
Commenter objected to dispositionCommenter's response (URI):
Comment :4. Section 3.1 Components says: "However, CC/PP processors MUST be able
to handle profiles that do not contain component type indicators." In a
strict RDF and RDFS environment this statement is, in fact, redundant.
Indeed, the ccpp schema (correctly) indicates that the range of a
ccpp:component property is ccpp:Component, ie, when used, an RDFS
processor would automatically infer the type.
I understand that a CC/PP processor is not necessarily an RDFS
processor, too, so adding this as a requirement might be o.k. But making
it clear that this requirement is not completely out of the blue might
help the reader.
Related issues: (space separated ids)
WG Notes: this text is in the first version of the specification verbatim. The point is that it is not necessary for components to specify a component type. If they do, life is good. If they don't then the CC/PP
processor must not fail. This is needed to allow some UAProf profiles to be valid CC/PP. The WG takes the point, but it wasn't
spelled out in the recommendation. We do say explicitly in that section that components MAY have type information. The text in question just spells out what a processor must do if such information is not available.
The WG proposes making no change.
Resolution: this text is in the first version of the specification verbatim. The point is that it is not necessary for components to specify a component type. If they do, life is good. If they don't then the CC/PP
processor must not fail. This is needed to allow some UAProf profiles to be valid CC/PP. The WG takes the point, but it wasn't
spelled out in the recommendation. We do say explicitly in that section that components MAY have type information. The text in question just spells out what a processor must do if such information is not available.
The WG proposes making no change. (Please make sure the resolution is adapted for public consumption)
Add a comment .