Re: Comments on CC/PP Structure and Vocabularies Last Call WD

Hi Francesco,

Thank you very much for your thorough and well thought out comments:

http://lists.w3.org/Archives/Public/www-mobile/2003Aug/0000.html

Here are our responses to your points.  Please let us know if it's ok.

Thanks,
Luu Tran
DIWG


0. General editorial remark.

While we don't use the term "delivery context", we do use its definition in the 
second sentence of section 1.  We will break up the following sentence:

"A CC/PP profile is a description of device capabilities and user preferences
that can be used to guide the adaptation of content presented to that device."

into two sentences:

"A CC/PP profile is a description of device capabilities and user preferences.
This is often referred to as a device's delivery context and can be used to
guide the adaptation of content presented to that device."


1. Section 1.1 Scope and normative elements

We will replace:

"(new CC/PP attributes sub-properties of ccpp:Attribute, new client components
based on ccpp:Component, etc.)."

with:

"(new CC/PP attributes are instances of ccpp:Attribute, new component classes
are subclasses of ccpp:Component, etc.)."


2. Section 2.2 Extensibility and namespaces

We will remove this paragraph.  The second NOTE after figure 2-7 makes it clear
that the URI does not necessarily point to a document.


3. Section 3.1 Components

We will replace:

"A ccpp:Component resource MAY have an rdf:type property (or equivalent RDF
structure) indicating what kind of client component it describes."

with:

"The object of a ccpp:component property MAY have an rdf:type property (or
equivalent RDF structure) indicating what kind of client component it describes"


4. Section 3.1 Components

The sample profile given is invalid because it violates the last paragraph of
section 3.1: "If a CC/PP profile uses any attribute that can appear on different
component types, then the type of any component on which such an attribute
appears MUST be indicated by an rdf:type property, or equivalent RDF."

The proposed wording would mean creating additional constraints that are not
normally present in RDF. In RDF, a class can be several types at once so a
component could be all the component types at the same time.


5. Section 3.1 Components

Profiles 1 - 3 would only be valid if they are based on a vocabulary with only
one component.  Otherwise, the use of ccpp-client:color is ambiguous and would
necessitate an explicit indication of the component type per the last paragraph
of section 3.1.  Even though the use of voc:screenSize in profile 1
disambiguates the component, the use of any ambiguous attribute necessitates an
explicit indication of the component type.

If a vocabulary defines ext-voc:GSMComponent and ext-voc:UMTSComponent, then
you're right that the use of voc:maxLatency in a profile is ambiguous.
Therefore, any component on which this attribute appears must have an explicit
type indication.  And a CC/PP processor must use this type information to
disambiguate the use of voc:maxLatency.  We don't understand how this is
contradictory to the cited paragraph.


6. Section 3.3 Defaults

Thank you, we will change "ccpp:default" to "ccpp:defaults".


7. Section 3.4 Distinguishing profile structure from attributes

We will replace:

"to describe all the non-RDF and non-CC/PP properties"

with:

"to describe properties that are not defined in the CC/PP or RDF namespaces."


8. Section 4.1.1.1 Values described by URIs

The anyURI type was removed because it's not considered the best way to handle
URI value properties in RDF.  We will remove section 4.1.1.1.


9. Section 5.1 CC/PP Document Conformance

Yes, we are referring to CC/PP profiles, not vocabularies when we use the term
"CC/PP document".


10. Section 5.1 CC/PP Document Conformance (conformance criterium 1)

We will replace:

"based on a vocabulary conforming to the RDF Schema in Appendix B"

with:

"based on a vocabulary derived from the RDF Schema in Appendix B"


11. Section 5.1 CC/PP Document Conformance (conformance criterium 5)

We will replace:

"The component names MAY be in rdf:type statements."

with:

"The component names MAY be in rdf:about or rdf:ID attributes"


12. Section 5.1 CC/PP Document Conformance (conformance criterium 6)

We will replace:

"Components MUST be associated with the CC/PP namespace or some subclass thereof."

with:

"Components MUST be indicated using a ccpp:component property where the
namespace used to qualify component is the CC/PP namespace or a UAProf namespace".


13. Section 5.1 CC/PP Document Conformance (conformance criterium 11)

We will replace:

"Defaults MUST be associated with the CC/PP namespace or some subclass thereof."

with:

"Defaults MUST be indicated using a ccpp:defaults or ccpp:Defaults property
where the namespace used to qualify defaults or Defaults is the CC/PP namespace
or a UAProf namespace".


14. Compatibility with UAProf

Compatibility with UAProf was part of the requirements for this document. We
believe the statements around compatibility are necessary and within the scope
of this document.  We agree that there may still be some work required, outside
the scope of this document, to bring full compatibility.  We want to encourage
interoperable implementations by requiring CC/PP consumers to accept existing
UAProf profiles, and hope that formal convergence between the specifications can
be achieved in the future.

Received on Wednesday, 27 August 2003 10:46:00 UTC