W3C home > Mailing lists > Public > www-mobile@w3.org > August 2003

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

From: Francesco CannistrÓ <fracan@inwind.it>
Date: Thu, 28 Aug 2003 11:07:08 +0200
Message-ID: <010801c36d43$c6389820$1d961d97@Matrix>
To: "Luu Tran" <Luu.Tran@Sun.COM>
Cc: <www-mobile@w3.org>, <w3c-di-wg@w3.org>

Hi Luu and DIWG.

Thank you  for your response.
All my minor remarks have been addressed, except a further perplexity
regarding point 10 of my earlier comments.
About the major issues, I think that the WG position concerning the
compatibility with UAProf (point 14 of my earlier comments) is not
satisfactory.  Here I provide some further argumentations that I hope you
will examine before closing definitively the issue (see inline comments).
Moreover, I think that the aspects regarding point 5 of my earlier comments
require further clarifications.
See inline comments for details.

Francesco CannistrÓ

> 0. General editorial remark.
> ...


> 1. Section 1.1 Scope and normative elements
> ...


> 2. Section 2.2 Extensibility and namespaces
> ...


> 3. Section 3.1 Components
> ...


> 4. Section 3.1 Components
> ...


> 5. Section 3.1 Components
> Profiles 1 - 3 would only be valid if they are based on a vocabulary with
> one component.  Otherwise, the use of ccpp-client:color is ambiguous and
> necessitate an explicit indication of the component type per the last
> 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,
> 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
> 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.

I think I have not been quite clear about this point.
The question is: what is an attribute that "can appear on different
component types"?
The answer seems to be: an attribute that could potentially be asserted for
components of different types.
But what are these attributes?
Well, since everyone could create a new vocabulary  defining a component
class that subclasses a component class already defined
within another vocabulary, then all the CC/PP attributes could have the
above prerogative.
Therefore, the contradiction ensues from the fact that saying that there
exist attributes that can appear on different component types implicitly
makes presume that attributes defined as belonging to a specific component
can be asserted for a component of that type only. In other words, it seems
to be implicitly agreed by the writer that the attributes that can appear on
component types are those ones that are defined with domain on
ccpp:Component. This would impede the definition of hierarchies of component
classes like those of the example I presented.
Let's consider again the voc:maxLatency attribute. A profile's author that
is using the "voc" vocabulary only could be not aware of the existence of
the "ext-voc" vocabulary and, therefore, in the profile he is writing, he
could omit the type indication. It seems clear to me that such a profile
would be valid, but your response seems to say the contrary. If it was so,
then all profiles that omit the type indication for a declared component
would not be valid.

Summarizing, the possible cases are two:

5-1. My interpretation of what you intend by attributes that "can appear on
different component types" is correct. In this case (as I demonstrated)
is a clear contradiction.

5-2. My interpretation is not correct. In this case you should clarify
what you intend by attributes that "can appear on different
component types" since the current wording clearly gives rise to ambiguous

Could you indicate the right case to me?

> 7. Section 3.4 Distinguishing profile structure from attributes
> ...


> 8. Section Values described by URIs
> ...

OK, I think  this is a very good decision.

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

Here I have some perplexities. In my earlier objection I had interpreted the
conformance criterion as if it was directed to a CC/PP document regarded at
RDF level. Therefore, since I had supposed that the stated sentence wanted
to say
that the RDF vocabulary on which a CC/PP document has to be based is the
CC/PP schema, I noted that the proposed wording had not the intended
Now I learn that my supposition was wrong and that the criterion is directed
to a CC/PP document regarded at CC/PP level. I.e., the conformance criterion
refers to the contents of a profile and the term "vocabulary" refers to an
attributes' vocabulary.
If this time my understanding is right, then I note that the criterion is
correct (as it is) since it affirms that a profile can take attributes from
one attributes' vocabulary only.

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


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

See below my further comments on compatibility with UAProf.

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

Same as the previous point.

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

The first step in order to solve a problem is to recognize its existence.
Since the CC/PP and the UAProf were born, this first step has never been
I perfectly understand that the compatibility with UAProf is an almost
inalienable requirement and I agree that the addressing of this issue would
be in the scope of the CC/PP spec if this was actually able to do so. But it
is not the case.
Saying that a UAProf namespace may be used instead of the CC/PP namespace
is not a solution, it is the problem itself!
As a preliminary and minor observation I note that the above statement has
real value and makes the spec under-specified since it is not also specified
what a UAProf namespace is (and this
is not as easy as it seems).
But even if we ignore this latter fact, the forcedly stated compatibility
with UAProf gives rise to lot of incongruities. Below I list only the main
technical incongruities, but IMO the really important problems regard the
general semantic compatibility at RDF level (since the CC/PP is an
application of RDF, isn't it?).

14-1. What about the UAProf attributes' vocabulary?
If you allow the use of a UAProf namespace, then it is implicit that you
also allow the leveraging
of the attributes' vocabulary defined by the corresponding UAProf schema.
Since it is certain that such a schema is not derived from the CC/PP schema,
all the sentences that state that a CC/PP vocabulary MUST be derived from
the CC/PP schema become contradictory (in particular, this applies to
criterion 1).

14-2. Supposing that, in order to avoid the previous contradiction, you
explicitly state that the attributes' vocabulary defined by a UAProf schema
can be regarded as a CC/PP vocabulary, then would you ignore the errors
contained in the UAProf schemas?
It is a fact that all the available UAProf schemas contain RDF semantic
and/or syntactic errors and, therefore, they
violate the requirement (implicitly stated by the CC/PP spec) that the
schema defining a vocabulary MUST conform to the syntax and semantics of the
RDF(S) specs.

14-3 What about the vocabularies defined through schemas that extend a
UAProf schema?
Also these vocabularies are not based on a schema derived from the CC/PP

In conclusion, as a general observation, I note that stating forcedly and
normatively that the CC/PP
is compatible with UAProf getsa mature interoperability between the two
standards out of the way (rather than bringing them nearer) since the
abovementioned "first
step" is again delayed. Furthermore, in this way more confusion would be
added since now folks could be induced to think (and they would not be wrong
at all) that  creating new
vocabularies in the UAProf style is a good practice that produces  valid
vocabularies (and, therefore, interoperability could be driven away always
more and more).
Received on Thursday, 28 August 2003 05:07:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:04 UTC