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

RE: general questions

From: Vidhya Gholkar <vidhya.gholkar@argogroup.com>
Date: Thu, 23 May 2002 15:27:36 +0100
Message-ID: <ABB39CCA97F2D840BB0FEDDEBD5A4D040A9E9BDE@mail-svr1.elstead-ad.elstead.argogroup.com>
To: <Stan@rga.com>, <www-mobile@w3.org>
Hi Stan,

The question about test bed and standards testing is quite complicated.
It only makes sense from the view point of End to End delivery of
capability information. So when someone says they are UAProf capable
what that **should** mean is that their applications can successfully
parse and resolve UAProf information. Mark Butler at HP labs is the best
person to say more on that, I think his DELI product does this. How this
information is dealt with after parsing is not and should not be in the
purview of standards.  Also, the standard gives a vocabulary, it is up
to users to verify the quality or otherwise of the values that the
vocabulary takes. We have already seen examples of inaccurate data -
but, standards don't police that. 

Another issue that you are referring to is that there are more relevant
attributes than that within, say the UAProf vocabulary, and you are
right. The UAProf vocabulary does not cover all of the capabilities of a
device whether  it be at the make, model or revision number. UAProf
provides a mechanism for you to increase the vocabulary but, you still
need to decide what that vocabulary is and also how to go about reliably
getting that information.

The idea at the core of UAProf and CC/PP is that you can get the defined
vocabulary from elsewhere and/or you can send  your info in a form that
another application has agreed to a priori understand.  Now, if you are
interested in capabilities that go beyond the UAProf vocabulary such as
that provided by UDQ you may not want or need to be UAProf or CC/PP

User Agents are not necessarily unique and so don't on their provide a
unique way of identifying devices. 

You mention XSL and so on. I don't believe that you want to, can or
should parameterise your application to use XSL (e.t.c.) to deal with
all the issues. It's not only a drag on performance but you simply
cannot at application design time take care of these issues (you won't
know what they are!). However, some of these issues can be dealt with
after the  basic application (or page) has been dynamically or
statically written if tools exist to take care of them.  There are
several 100's of these little problems which the developer doesn't want
to program for and so needs these tools to 'invisibly' deal with the
issues - these Device Targeting tools (like UDT) will on the fly provide
workarounds and corrections.  

I hope that some of your questions have been answered above!



-----Original Message-----
From: Stan@rga.com [mailto:Stan@rga.com]
Sent: 23 May 2002 05:17
To: www-mobile@w3.org
Cc: Mark_Butler@hplb.hpl.hp.com; jwilliams@wc-group.com; Vidhya Gholkar
Subject: RE: general questions

Thanks very much for your excellent feedback! I'm still in process of
viewing all the resources you send me. 

I would like to add some points out of practical experience which might
nothing new for you:

My understanding is that there will be a vocabulary for each category of
information appliance. Just from looking at UAprof I can tell cases
where it
doesn't completely cover the device. Most of browseres have anomalies
described in the profiles, i.e. a) WML lets you specify a title of deck,
certain browser (all UP <5) just don't display them and b.) WML lets you
create numbered lists but certain browsers don't display them or only
first line. I'm sure that you will discover the same thing when you
using i-mode devices and handhelds.  I'm very much aware that these are
details, my point and question is: Is or will there be a testing
where these standards will be tested in a real world environment? 

I think a good recognition scheme needs to have fallback mechanisms
profiles) and priorities. Default meaning when we recognize in the HTTP
header that the device accepts WML but just doesn't match any of the
specific ones. Priority meaning a fixed order in which the profiles are
checked to enable default devices. This could be either indicated in the
device profile itself or in an external map.

A note on the user-agent definition which I assume is the main indicator
a device. I'm wondering whether a regex expression of that might be
since the gateway or a proxy might alter the user-agent and such an
expression might have a higher success rate. Also sometimes browsers
such as
the embedded opera have the screen dimensions within the user agent
in other words the user-agent can vary even when it is the same browser,
regex can solve that.

Certain browser support several markup languages, where certain ml's
in a higher quality user interfaces then the others. Can this be

As I mentioned I unfortunately have almost no RDF knowledge and working
experience yet besides some RSS documents. Would in case of deli I need
deal with a  com.hp.hpl.httpneg.CcppProfile instance and would need to
the getter methods to go through the elements I'm interested in? Isn't
parsing RDF a heavy process?

Thinking aloud: What I would need from such a system when using xsl and
is 1.) the decission what output format will be  delivered to the client
HTML1.0, HTML3.2, XHTML, WML etc  2.) I would need ALL the device
passed to the stylesheet as parameters so that the stylesheet can create
target markup based on that properties.  Am I missing something? That
thinking brings me to the point of simpler device specifications that
key/value based such as:

<device-category value="phone" targetFormat="wml1.1"
<property name="wap.softkey" value="2" />
<property name="wap.width.x" value="100" />

What would need to be specified are the property names and the value
I'm basically proposing a set of property names instead of a full
vocabulary. The approach might too much practice oriented.

Is that too simplified? Why do we need RDF? Would my RDF-CC/PP result

Looking forward to hear back from you (I will be out of email reach till

Stan Wiechers

The new Communications of the ACM has a special this month about "The
Adaptive Web", looks promising.


-----Original Message-----
From: Butler, Mark
To: 'Stan@rga.com'; www-mobile@w3.org
Sent: 5/20/02 6:55 AM
Subject: 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
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

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

At the moment there is no institution officially collecting profiles but
useful profile resource is available here

Currently the Ericsson T68 and T39 phones and the Trium Eclipse use

Note that there is no guarantee that these profiles are fully CC/PP or
vocabulary compliant - for more details of this see
> 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
the current CC/PP representation is unnecessarily complex but that it is
current XML serialisation of RDF rather than RDF itself that is causing
problem. However I'm sure this opinion is controversial! For more
on this see my report "Some questions and answers on CC/PP and UAProf"
IBM's report presented at the Delivery Context Workshop:

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

i) CC/PP was meant to be backward compatible with UAProf, and UAProf
RDF. The UAProf activity has now finished that makes it very difficult
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. 

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
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
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
candidate recommendation. However unfortunately because of ii) I don't
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
and I don't implement in DELI. However you don't have to use proxies to
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
this. However this protocol is just a W3C note, not a W3C
This is because protocol work is outside the current CC/PP charter. The
Device Independence Working Group is also expected to look at protocol
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
for servers, for more details see

> 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 -
the Resource section
and some technical reports and software are available from my personal
page - see

Any further questions please let me know and we will welcome feedback on
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
Internet: http://www-uk.hpl.hp.com/people/marbut/
Received on Thursday, 23 May 2002 10:27:42 UTC

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