RE: general questions

Hi Stan

> I got experience in creating websites that adapt to output format and
> special features of information appliances. The approach we 
> had until now was a if this than that and so on, by examining HTTP 
> header. I was hoping that we could use CC/PP to take that approach 
> to the next  level, reading all the documents (I'm not a RDF guru) 
> I'm left with some questions.
> 
> 1.) My understanding is that companies creating devices and 
> browsers are
> supposed to create CC/PP definitions of their product which 
> could be used in
> adaptive websites. Is/Are there an institution(s) collecting them? 

It's actually more complicated than this. At the moment if a company wants
to use CC/PP they first have to either i) use the WAP Forum UAProf
vocabulary to describe their product or ii) also define their own
vocabulary. Then they can come up with a profile to describe their product. 

The W3C Device Independence Working Group
http://www.w3.org/2001/di/ 
is currently going through a recharter process, and it is expected they will
work on a core vocabulary for describing device capabilities. When this is
available, this will provide a starting point for companies to create
vocabularies.

At the moment there is no institution officially collecting profiles but one
useful profile resource is available here
http://pixels.pixelpark.com/~koch/uaprof/

Currently the Ericsson T68 and T39 phones and the Trium Eclipse use UAProf. 
http://mobileinternet.ericsson.com/UAprof/T68R1.xml
http://mobileinternet.ericsson.com/UAprof/T39.xml
http://www.mitsubishi-telecom.com/profiles/eclipse.ua

Note that there is no guarantee that these profiles are fully CC/PP or
vocabulary compliant - for more details of this see
http://www-uk.hpl.hp.com/people/marbut/someQuestionsOnCCPP.htm
 
> 2.) From reading the spec  I found that using RDF doesn't 
> make that problem
> easier to solve. Wouldn't it make sense to take a more straigforward
> approach? I like the idea of having several layers of specs 
> making up the
> whole spec (default, user, ...) . Couldn't that be expressed 
> in more simple
> key/value method? 

There has been quite a bit of discussion on this. My personal opinion is yes
the current CC/PP representation is unnecessarily complex but that it is the
current XML serialisation of RDF rather than RDF itself that is causing the
problem. However I'm sure this opinion is controversial! For more background
on this see my report "Some questions and answers on CC/PP and UAProf" or
IBM's report presented at the Delivery Context Workshop:
http://www.w3.org/2002/02/DIWS/submission/aschadeCompositeProfileInformation
.html

However there are some problems with changing CC/PP's underlying
representation:

i) CC/PP was meant to be backward compatible with UAProf, and UAProf adopted
RDF. The UAProf activity has now finished that makes it very difficult to
submit changes to UAProf. So if maintaining backward compatibility with
UAProf is essential to CC/PP we are stuck with RDF. 

ii) The CC/PP charter expressly said CC/PP should be based on RDF, which
makes it very difficult to change the underlying representation of CC/PP
without re-chartering the working group. 
http://www.w3.org/2002/01/ccpp/charter-20020116.html

iii) The CC/PP Structure and Vocabularies document is not currently at a
point where people can submit comments. Last call for comments on the
working draft finished in March 2001. When this document moves to candiate
recommendation (hopefully soon, we are actively working on this at the
moment) you will be able to submit comments again. 

However I am concious these are mainly "political" rather than technical
issues. So if you really think that CC/PP should not be based on RDF, or you
can propose better ways of using RDF in CC/PP, then I would urge you to
submit comments to that effect during the call for comments after we reach
candidate recommendation. However unfortunately because of ii) I don't think
it will be possible to address those comments to CR. 

> 3.) Most documents talk about a proxy server analyzing the 
> request. Isn't
> that already too specific? 

I must confess I am not convinced about the proxy functionality in my CC/PP
and I don't implement in DELI. However you don't have to use proxies to use
CC/PP. Again if you have specific comments, please submit them at CR. 

> I believe that in most cases a sever local
> component could do the job better. 

I don't understand what you mean by a server local component - could you
give more details? Do you just mean a database of device capabilities
located on the server?

> Related to question 1.) I 
> was wondering
> if there is a notification approach in development that lets 
> registered
> components know when there is an update of device profiles? 

Currently a protocol has been proposed for CC/PP but it doesn't work like
this. However this protocol is just a W3C note, not a W3C recommendation.
This is because protocol work is outside the current CC/PP charter. The
Device Independence Working Group is also expected to look at protocol work
when it is rechartered. So if you have a proposal for a better protocol,
then please submit it to the DI-WG - but preferably after the recharter?

> Is there a DOM
> like pseudo API for components that reflect device 
> capabilities? 

Yes, but it is not standarised. For example DELI provides an API like this
for servers, for more details see
http://delicon.sourceforge.net/

> How does a
> proxy server fit into the approach that user preferences are usually
> accesible through components available on a app server and 
> not accesible by
> the proxy server? At what point do all properties come together into a
> unified object?

I wouldn't worry about proxy servers unless you have a specific need for
this. DELI demonstrates how you can use CC/PP between a CC/PP aware or
legacy client and an app server. 

More resources on CC/PP are available from the Working Group web page - see
the Resource section
http://www.w3.org/Mobile/CCPP/
and some technical reports and software are available from my personal web
page - see
http://www-uk.hpl.hp.com/people/marbut/

Any further questions please let me know and we will welcome feedback on the
CC/PP Structures and Vocabularies document when we reach Candidate
Recommendation which will hopefully occur in the next month. 

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 Monday, 20 May 2002 06:56:25 UTC