Re: Issues and future work for CC/PP

Mark,

Here's is our list of proposed CC/PP issues and work items:

External profile representation

We need to clearly define the syntax for an externalized
CC/PP profile to simplify parsing and to avoid proliferation
of different CC/PP "flavors". Principally, we see the
following possible approaches:

- Replace RDF with simple XML. We envisage two DTDs, one
  for the schema definition and a another one for actual
  profile instances. This is our favorite approach as it
  would make things much easier and solve
  machine-readability issue of schema definitions (see 2).
- Use RDF but define *one* valid RDF externalization which
  can be parsed with reasonable efficiency.
- Use RDF but permit several syntactic forms. This must be
  done with care.

Machine-readability of CC/PP schema definitions

Schema definitions must be machine-readable thus enabling
the development of schema-transparent CC/PP processing
software that can cope with schema evolution. Making the
schema definition machine-readable means that a particular
profile schema can be loaded at runtime and does not have
to be hardcoded.

Property type system

Typed properties simplify the programmatic use of CC/PP
profiles. Some types imply default relations between property
values that can be used when comparing profiles (for instance,
the relational operators "<", "<=", "==", ">=", ">" for values
of integer type). We need to define an extensible type system
for properties and mandate the use of typed properties. As it
may not be sufficient to define a set of base property types
(boolean, literal, number etc)  and a set of composition
specifiers (bag, sequence, etc), we may need some sort of
extension mechanism. XML schema would be a candidate for this.
The machine-readability of the schema definition must be
preserved whatever typing system and extension mechanism is
adopted.

The  question what values are valid for a given property is
related to the property type system. A schema definition must
also enable the definition of valid values for any property it
contains. This can be done implicitly via the property type or
more specifically by explicitly defining the set of valid
values, e.g., for literal enumeration types.

Profile validation

We need to specify when a CC/PP profile is valid vis-a-vis a
CC/PP schema.  The schema represents a sort of contract between
the sender and the receiver of the profile information as it
indicates
- for the sender what information can be sent in what form
- for the receiver what questions it may ask, i.e. what
  properties it may query and what value(s) it may expect in
  response.

If profiles do not adhere to the schema they use, a receiving
entity can only guess what properties are contained in the
profile, what types are used to represent the property values,
and what these values actually mean. In this case the profile
does not provide much value for the receiver. Validation is in
our opinion the only way to guarantee that the contract between
the sender and the recipient is upheld. On the other hand,
strictly requiring that a profile can only contain the
properties defined in the schema it uses actually breaks
profile extensibility. A way to deal with this is to define
different levels of strictness for profile validation. (see my
earlier note on validation on the mailing list).

Transfer syntax

Currently there is only a proposed syntax based on HTTPExt.
Given the limited support of HTTPExt in current web servers
and proxies we have to standardize an HTTP-compliant transfer
syntax for transporting CC/PP profiles.

Core vocabulary

In order to encourage a wider deployment of CC/PP we have to
define a core vocabulary (core profile schema). This would
enable separate development efforts for both sending and
receiving entities of CC/PP information as both parties would
know what data they can sent in what format/what data they have
to expect.

Profile-diffs

Adopt the useful concept of the UAProf profile-diffs that can
be applied as deltas to base profiles. Explicitly specify how
profile-diffs are to be applied to base profiles (resolution
policies) and when this can be done (involves work of schema
compatibility).

Kind regards,
Andreas Schade
IBM Zurich Research Lab



|---------+----------------------------->
|         |           "Butler, Mark"    |
|         |           <Mark_Butler@hplb.|
|         |           hpl.hp.com>       |
|         |           Sent by:          |
|         |           www-mobile-request|
|         |           @w3.org           |
|         |                             |
|         |                             |
|         |           13.06.2002 18:02  |
|         |           Please respond to |
|         |           "Butler, Mark"    |
|         |                             |
|---------+----------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                             |
  |       To:       "'www-mobile@w3.org'" <www-mobile@w3.org>                                                                                   |
  |       cc:                                                                                                                                   |
  |       Subject:  Issues and future work for CC/PP                                                                                            |
  >---------------------------------------------------------------------------------------------------------------------------------------------|





Hi all

A while back I said that it is not possible to submit issues to the CC/PP
Working Group until we get to the next stage in the process (Candidate
Recommendation). After some discussion with the W3C this week, my position
has changed on this.

If you have any issues with CC/PP, or you have any suggestions for future
work, then please submit them to me via this email list. It may not be
possible to reply to these issues until the next stage in the process, but
there is no reason why we can't collect them now. I'll take responsibility
for collecting and coordinating these issues and requests.

Note this is a formal process so you need to make it clear that you want me
to respond to the posting in that way. Furthermore it would be helpful if
you could structure your issue / suggestion in the following way:
- A summary sentence that describes the issue / suggestion.
- A paragraph that gives more details

Also note I'm not planning to go back through www-mobile looking for
issues,
so if you feel something needs to be addressed you need to post it again or
refer me to the post you made. Hope that is okay!

PS just in case people haven't seen it already, you may be interested in
JSR-188 on CC/PP - see
http://jcp.org/jsr/detail/188.jsp

best regards

Mark H. Butler, PhD
W3C CC/PP Working Group Chair
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Wednesday, 19 June 2002 10:53:19 UTC