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

Hi Luu, DIWG,

I accept your decisions, but I do not agree with your response.
See inline comments for more details.

Best Regards,
Francesco Cannistrà

> 5. Section 3.1 Components
>
> It seems that the problems you point out arise only when the vocabulary
> context in which a producer creates a profile is different from the
> vocabulary context in which a consumer uses a profile.
> ...

The CC/PP spec does not say anything of the contexts you are mentioning. It
just says that attributes that could appear within different component types
must be provided with a type indication. It does not say what these
attributes are or whether an attribute defined as specific to a component
type could even be asserted for more specific components types (and what
would be the implications of the above statement in such a case).
I think all your considerations regard implementation. The author of a
profile or of a vocabulary is not required to know the consumer's context.
The basic idea inside CC/PP (that motivates the choice of RDF as its
foundation) is that profiles are suitable for being "consumed" in different
RDF compliant contexts.
Furthermore, the consumer's context could be enriched over time with new
vocabularies. The only constraint the consumer can impose is that it can
manage meaningfully only the profiles referencing the vocabularies it
currently recognizes. However, this is mere implementation affair. It is the
consumer that imposes such limitation, not CC/PP.
I think that the main responsibility about the consistency of a profile is
of its author (that could even be not a human). If the author indicates
explicitly the component type, then the component is of that type. But,
since the component type could even be not indicated, then CC/PP should
provide an unambiguous (and not context-dependent) criterion for deducing
the component type. Such criterion is already provided by RDF itself (the
entailment rule): the type would be the most specific component type among
those ones to which can belong the attributes contained in the currently
defined component.
If the author wanted to intend another component type, then this would be an
error of the author: the profile would be valid but it would be not
semantically consistent with the described delivery context. It is the same
as if the author declared an (allowed) attribute value that does not match a
capability of the described device.

> if a consumer is not configured
> to recognize a particular namespace and associate it with a particular
> vocabulary, then it will not be able to validate any profile which uses
> that namespace.

This is, again, an implementation concern. The focus of the consumer should
be on vocabularies. The namespaces identify vocabularies. If the consumer
does not recognize a vocabulary (and the associated semantics), then this
does not mean the consumer cannot perform a basic processing and provide a
huge access to profile's data. Furthermore, as I said above, the knowledge
base of a "consumer" can increase over time through new vocabularies (it is
not a simple namespace configuration concern). If the processors the CC/PP
is directed to had to be designed in advance for handling olny certain
vocabularies then CC/PP would really be  broken (I can image many
different-purpose processors).

> 14. Compatibility with UAProf
>
> The validity of UAProf namespaces applies to qualifiers of components
> and defaults/Defaults.  This does not imply use of the UAProf attribute
> vocabulary.

Does this make sense?
The only usefulness of allowing uaprof:component and uaprof:defaults
(instead of ccpp:component and ccpp:defaults) is to provide the facility of
leveraging the rich UAProf vocabulary to construct profiles.

> We do acknowledge that there is room for further convergence, but much
> of that work is beyond the scope of this document.  We would like to
> defer what might be done within the scope of this document to a
> potential future release.

The CC/PP spec does not say this: it states that CC/PP and UAProf are
compatible. It does not say anything more.

Received on Wednesday, 10 September 2003 14:15:28 UTC