RE: Issues and future work for CC/PP

The context path sounds very good. From an API perspective this gives the
ability to request a profile attribute using this path, if there is no
direct method call on an object representing a given profile.

The flexibility afforded by this approach also allows a parser to handle a
profile (and create a profile object) that could have attributes above and
beyond those of a core vocabulary. These extra attributes that a profile
object based on the core vocabulary would not have an accessor for could
still be stored in the object and accessed through a generic method, using
the context path.

I suspect vendors will inevitably add new attributes to the core vocabulary
on a proprietary basis to differentiate their devices/highlight special
capabilities. While a ccpp implementation may not necessarily understand the
semantic meaning of the new attributes, having them available and certainly
not choking on them is a plus.

Erich Izdepski
Senior Software Engineer
Cysive, Inc.


-----Original Message-----
From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com]
Sent: Friday, June 21, 2002 10:52 AM
To: www-mobile@w3.org; 'w3c-ccpp-wg@w3.org'
Subject: RE: Issues and future work for CC/PP



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

Profile
+--HardwarePlatform
|  +--defaults
|  |  +--ScreenWidth = 80
|  |  +--ScreenHeigth = 100
|  |
|  +-ColorCapable = Yes
|
+--SoftwarePlatform
   +--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>
ELEMENT = PROPERTY | STRUCTURE
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#"
 xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#">
 <rdf:Description>
  <prf:HardwarePlatform>
   <rdf:Description>
    <prf:defaults>
     <rdf:Description>
      <prf:ScreenWidth>80</prf:ScreenWidth>
      <prf:ScreenHeight>100</prf:ScreenHeight>
     </rdf:Description>
    </prf:defaults>
    <prf:ColorCapable>Yes</prf:ColorCapable>
   </rdf:Description>
  </prf:HardwarePlatform>
  <prf:SoftwarePlatform>
   <rdf:Description>
    <prf:CcppAccept>
     <rdf:Bag>
      <rdf:li>text/html</rdf:li>
      <rdf:li>image/jpeg</rdf:li>
     </rdf:Bag>
    </prf:CcppAccept>
   </rdf:Description>
  </prf:SoftwarePlatform>
 </rdf:Description>
</rdf:RDF>

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

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

Received on Friday, 21 June 2002 11:21:34 UTC