RE: general questions

 
>We actually had that XSLT approach and it worked real nice. We knew
what
>information we were getting since we defined that all in our
application.
>Question:  Why wouldn't you use that when using UAProf, you know what
>information you get back regarding the device, you should know what is
>optional and what is required. It is definitly not a performance issue
at
>all. I'm not sure why it should be one?


XSLT's do template matching, have control structures, pass paramaters,
instatiate templates, call libraries, select nodes e.t.c. e.tc. and all
this takes time.  So in addition to the number and type of
transformations on a page that are being done, there are a maximum
number of processes your processor(s) can handle and this leads to
issues of latency, fall over and so on. I am sure you get the picture.
(I work with people whose requirements run into ten's of thousands of
transactions per second ... )


>>User Agents are not necessarily unique and so don't on their provide a
>>unique way of identifying devices. 
>So how will they be identified? 

Using ingenuity :)

>Stan Wiechers


Vidhya





-----Original Message-----
From: Vidhya Gholkar [mailto:vidhya.gholkar@argogroup.com]
Sent: Thursday, May 23, 2002 10:28 AM
To: Stan@rga.com; www-mobile@w3.org
Subject: RE: general questions


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
enabled! 

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!

Regards

Vidhya

-----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
be
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
not
described in the profiles, i.e. a) WML lets you specify a title of deck,
but
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
the
first line. I'm sure that you will discover the same thing when you
start
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
environment
where these standards will be tested in a real world environment? 

I think a good recognition scheme needs to have fallback mechanisms
(default
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
for
a device. I'm wondering whether a regex expression of that might be
helpful
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
string,
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
result
in a higher quality user interfaces then the others. Can this be
described?

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
to
deal with a  com.hp.hpl.httpneg.CcppProfile instance and would need to
use
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
xml
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
properties
passed to the stylesheet as parameters so that the stylesheet can create
the
target markup based on that properties.  Am I missing something? That
thinking brings me to the point of simpler device specifications that
are
key/value based such as:

<device-category value="phone" targetFormat="wml1.1"
targetNameSpace=".."
mime-type="..."/>
<user-agent-regex>*UP4.*</user-agent-regex>
<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
type.
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
the
same?

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

Best,
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
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/aschadeCompositeProfileInforma
tion
.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 Thursday, 23 May 2002 12:08:17 UTC