W3C home > Mailing lists > Public > www-mobile@w3.org > June 2002

RE: Issues and future work for CC/PP

From: Butler, Mark <Mark_Butler@hplb.hpl.hp.com>
Date: Fri, 21 Jun 2002 15:51:44 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04501933@0-mail-1.hpl.hp.com>
To: www-mobile@w3.org, "'w3c-ccpp-wg@w3.org'" <w3c-ccpp-wg@w3.org>

Hi Tayeb

Thanks for your post. I think you did a very good job of covering the
important points here. 

I'm going to outline my current thinking, but I'm working on a document that
explains this much more thoroughly. I have a "refactoring" of CC/PP that is
based on the observation that CC/PP profiles contain two types of elements:
cc/pp properties e.g. <prf:ScreenWidth>400</prf:ScreenWidth> and cc/pp
structure e.g. components, defaults, capability chaining and proxies.
Furthermore whereas UAProf is limited in that it constrains profiles to a
two level hierarchy i.e. it permits two or three levels of structure,
ideally CC/PP should permit many more levels of structure. This would allow
us to implement features more similiar to media feature sets as Tayeb
mentions. Furthermore ideally it should be possible for vocabularies to
define their own methods of structuring data if necessary. 

Just to give a taste of this approach, a typical profile with this new data
model would look like this

|  +--defaults
|  |  +--ScreenWidth = 80
|  |  +--ScreenHeigth = 100
|  |
|  +-ColorCapable = Yes
   +--CcppAccept = [text/html, image/jpeg]

which should be reasonably familiar from the current CC/PP WD. However a new
idea is that this data structure can be queried to produce a view I call a
context path e.g.

PropertyValue ContextPath
80            Profile/HardwarePlatform/defaults/ScreenWidth
100           Profile/HardwarePlatform/defaults/ScreenHeight
Yes		  Profile/HardwarePlatform/ColorCapable
[text/html, image/jpeg]	Profile/SoftwarePlatform/CcppAccept

The context path information is used in resolution (i.e. non-defaults
override defaults, the UAProf resolution rules etc). Then we can use a
simple grammer (many thanks to Graham Klyne here for invaluable help) to
express this data structure in XML/RDF 

PROFILE = <rdf:RDF namespace information> DESCRIPTION </rdf:RDF>
DESCRIPTION = <rdf:Description> ELEMENT* </rdf:Description>
STRUCTURE = <structureName> DESCRIPTION* </structureName>
PROPERTY = <propertyName> PROPERTYVALUE </propertyName>

which gives us profiles such as 

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

however here we have constrained our XML/RDF so it is easily processable by
XML processors - to build a tree just omit the rdf:Description nodes. As
other people have commented, being able to process profiles using XML
processors is very desirable. 

Obviously a priority here is to backward compatible with UAProf. In my draft
I'm going to provide some examples of how this can be done (without changing
UAProf) along with some examples of how this new data structure can support
all the existing CC/PP functionality. 

Does this seem like an attractive approach, assuming we can retain backward

Mark H. Butler, PhD
Research Scientist                HP Labs Bristol
Internet: http://www-uk.hpl.hp.com/people/marbut/
Received on Friday, 21 June 2002 10:52:09 UTC

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