FW : [Moderator Action] Re: FW: CC/PP Structure and Vocabularies last call working draft - acouple of questions/issues from Claudia

--
Stephane Boyera		stephane@w3.org
W3C				+33 (0) 4 92 38 78 34 
BP 93				fax: +33 (0) 4 92 38 78 22
F-06902 Sophia Antipolis Cedex,		  
France
 

-----Original Message-----
From: Claudia Alvarez Rolins [mailto:claudia@telemidia.puc-rio.br] 
Sent: Friday, April 04, 2003 9:12 PM
To: Luu Tran
Cc: Butler, Mark; www-mobile@w3.org
Subject: [Moderator Action] Re: FW: CC/PP Structure and Vocabularies
last call working draft - acouple of questions/issues from Claudia




Hi Luu,

many thanks for your reply and for the additional information that you
have provided me.

As I said to Mark, I would like very much to join and help the group but
unfortunately, I have a couple of months to complete my master thesis
which is now my highest priority. Anyway, I will follow the group work
on CC/PP and maybe in the future, be in a situation where I can offer
myself to make contributions to the group.

Best Regards,

CR
----- Original Message -----
From: "Luu Tran" <Luu.Tran@Sun.COM>
To: <claudia@telemidia.puc-rio.br>
Cc: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>; <www-mobile@w3.org>
Sent: Friday, April 04, 2003 3:30 PM
Subject: Re: FW: CC/PP Structure and Vocabularies last call working
draft - acouple of questions/issues from Claudia


> Hi Mark, Claudia,
>
> Thanks much for your comments.  Please see my responses below.
>
> Thanks,
> Luu
>
> Butler, Mark wrote:
> > FYI - anybody else got any views on the issues Claudia raises?
> >
> > -----Original Message-----
> > From: Butler, Mark
> > Sent: 04 April 2003 11:08
> > To: 'claudia@telemidia.puc-rio.br'; 'luu.tran@sun.com'
> > Subject: FW: CC/PP Structure and Vocabularies last call working 
> > draft - a couple of questions/issues from Claudia
> >
> >
> > Hi Claudia
> >
> > See my responses to your questions and issues below
> >
> > -----Original Message-----
> > From: Claudia Alvarez Rolins [mailto:claudia@telemidia.puc-rio.br]
> > Sent: 04 April 2003 00:30
> > To: Butler, Mark
> > Subject: Fw: CC/PP Structure and Vocabularies last call working 
> > draft - a couple of questions/issues from Claudia
> >
> >
> >>Questions and Issues
> >
> >
> >>1) What is the difference between content adaptation and
> >
> > contextualization?
> >
> > Content adaptation is the process of adapting content (say in XML) 
> > to various target devices (e.g. HTML, WML, XHTML). As for
contextualization,
> > I'm afraid I don't know what that means - but the W3C DI-WG has been
working
> > on a glossary which presumably defines it - Luu? Is the term 
> > contextualization used in the CC/PP WD? If so is it not defined in 
> > the glossary at the end?
>
> Contextualization is used once in the introduction, but not defined in

> the glossary.  I'm not sure what it means either, but by the way it's 
> used, I'd guess that contextualization is the process of setting 
> context, i.e. context is the output.  This is different from content 
> adaptation which is one way of reacting to context, i.e. context is 
> the input.  I agree that we either need to remove this term, or define

> it in the glossary.
>
> >>2) Proxy behavior was removed from CC/PP Structure and Vocabularies 
> >>and nowdays this specification indicates the use of CC/PP as a 
> >>profile data format to guide/orient a server on determining the most

> >>appropriate form of a resource to deliver to a client. However 
> >>content adaptation can also be performed at the client side during 
> >>the content presentation (also known as dynamic adaptation).
> >
> >
> > Yes you can do content adaptation at the client side, but at the 
> > moment
the
> > technology I would recommend there is Cascading Stylesheets Media
Queries -
> > see the W3C CSS work for more details. Whereas CC/PP only defines a 
> > data format, CSS MQ also defines a query format. Therefore it is 
> > easier to
use.
> > Of course, CSS MQ defines its own vocabulary. There was some
disagreement in
> > the W3C about whether CSS MQ should exist, or whether it should use
CC/PP.
> > However as I've described in many of my reports I think CC/PP is 
> > much
more
> > complicated to deploy than it needs to be, and this is due in part 
> > from unnecessary complexity it inherits from RDF/XML. CSS MQ is a 
> > much more pragmatic approach to the problem. I see the DI-WG core 
> > device characteristics work as addressing the need for a common 
> > vocabulary
here.
> >
> >
> >>Is CC/PP not indicated to describe context information (e.g.: the 
> >>origin server capabilities) that would be helpful to support the 
> >>content
> >
> > adaptation
> >
> >>process at the client side?
> >
> >
> > You could use CC/PP in this way and then use a process a bit more 
> > like transparent content negotiation in HTTP. One of my earlier 
> > papers
describes
> > a content negotiation approach with CC/PP. However it is actually 
> > quite difficult to do things like this in CC/PP, because if you 
> > strictly
follow
> > the CC/PP WD, CC/PP can't express disjunctions or preference 
> > ordering.
> >
> >
> >>Is CC/PP only useful to describe client capabilities?
> >
> >
> > For the moment, that is how most people are using it, so that is 
> > what is reflected in the current WD. In the future this may change 
> > though. The
CC/PP
> > work needs more support so if you are interested in this perhaps you
would
> > consider joining and helping?
> >
> >
> >>3) If a proxy behavior was removed from CC/PP Structure and
> >
> > Vocabularies,
> >
> >>is it correct to maintain the sentence "It is structured to allow a
client
> >
> >
> >>and/or a proxy to describe their capabilities by reference to a 
> >>standard profile...." at the fourth paragraph of the Introduction 
> >>section?
> >
> >
> > No, this sentence probably needs rewording so I suggest you raise it

> > formally with the DI-WG as they describe.
>
> Thanks for catching that.  I'll remove it for the next revision.
>
> >>4) Why the issues on profile resolution mechanism not addressed is 
> >>the Working Draft from 25 March 2003? Will resolution rules adopted 
> >>by
UAPROF
> >>(override, locked, append) and data types be treated within the
> >
> > rdfs:comment
> >
> >>property?
> >
> >
> > because unlike UAProf, CC/PP does not have any standardised 
> > processing
or
> > resolution policy. I think this is a mistake - without a 
> > standardised processing model, different processors might do very 
> > different things. I have raised this issue with the CC/PP WG, but it

> > has been very hard to introduce changes to the CC/PP WD for two 
> > reasons
> > - lack of group members and interest in the group
> > - restrictions due to the current WG charter
> > therefore it was decided not to address this in the current version.
>
> I'd also add that the DI-WG is chartered to produce a CC/PP protocol 
> document, in which we can address processing/resolution.
>
> > I'm sure the issue list would be interesting reading for you, but at

> > the moment it isn't public. Try writing to Luu or the DI-WG and ask 
> > if you
can
> > see a copy, because the DI-WG has a public policy so it would be
interesting
> > to see if this extends to the CC/PP Work.
>
> A public version of the issues list is at:
>
> http://www.w3.org/2003/03/ccpp-cr-issues-20030320.html
>
> > In JSR-188, we solve this problem by just adopting the UAProf 
> > resolution model. In a way, JSR-188 is really just focusing on 
> > UAProf as that is
the
> > only CC/PP application that is defined in enough detail to be
implemented.
> >
> >
> >>5) Is there any test or example that shows how CC/PP can be used to 
> >>describe users personal preference? Or CC/PP not applied to describe

> >>this type of context information?
> >
> >
> > this is a difficult one. There are a couple of viewpoints i.e.
> >
> > i) if we express personal preferences, then there are privacy issues

> > so
we
> > have to adopt a privacy framework like P3P
> >
> > ii) does P3P really work? It is just a way of a site claiming it has

> > a certain privacy policy - what if it lies? Therefore surely if 
> > there is privacy concerns about a piece of information surely we 
> > should not send
it?
> > Privacy is a complicated issue. For example people have suggested 
> > that
if a
> > PC says it only audio capable, then it indicates a blind user, so 
> > there
is
> > the possibility of discrimination, so we should use a privacy 
> > system. However how do we avoid this - if we send no information, we

> > are in the
same
> > situation as if we don't use CC/PP? Personally I don't understand 
> > how
you
> > can use specs to stop discrimination, because you don't know how 
> > people
are
> > going to discriminate. For example I might decide to discriminate
against
> > Nigerians, because that's where all the spam comes from, and I might

> > do
that
> > by maintaining a list of Nigerian IP subnets - how do you stop me 
> > doing
that
> > (this is a theoretical example of course)?
> >
> > iii) it sounds like to send personal preferences, we need something 
> > more complicated than CC/PP. However we need CC/PP to solve some 
> > real issues today e.g. whether a device supports frames, whether it 
> > is
mime/multipart
> > capable etc. So why not just use CC/PP for describing client
capabilities
> > for now?
> >
> > iv) The other adaptation information that servers need is language 
> > preferences? Is this personal information?
>
> I agree with Mark.  I'd just add that the CC/PP default override 
> mechanism can be used to indicate a limited level of personal 
> capability preferences.  For example, even if my device can display 
> color images, I may choose to configure it to only request black and 
> white images to reduce network bandwidth consumption.  As Mark 
> describes, conveying personal preferences unrelated to device 
> capabilities is difficult and (in my view) inappropriate as part of 
> CC/PP profiles.  There is another more widely accepted industry effort

> underway to address this problem:
>
> http://www.projectliberty.org/
>
> >>6) Why does Tayeb Lemlouma propose the Universal Profiling in a 
> >>different direction than UAPROF? Could the efforts be joined?
> >
> >
> > The best person to ask here would be Tayeb. I could tell you my 
> > opinion,
but
> > it would just be my opinion and Tayeb might disagree. However I 
> > think
you
> > are highlighting that there is a need for a standard vocabulary 
> > here,
not
> > lots of separate ones like UAProf, Universal Profiling etc and that 
> > need should be addressed by the DI-WG in the core device 
> > characteristics
work.
> >
> >
> >>7) While reading the CC/PP Structure and Vocabulary I always have 
> >>the feeling that CC/PP only supports the three
> >>components: hardware, software and browser. Shouldn´t this 
> >>specification be more explicit and describe that other components 
> >>could be created such as UAPROF did?
> >
> >
> > No, because the spec just defines a structure, not a vocabulary. The

> > components it gives are examples, so you don't have to use them, you

> > can create others. Despite the specs length, it doesn't really say 
> > that
much.
> >
> > Personally I don't think that components actually serve any purpose 
> > in CC/PP, and they actually make processing more difficult so I 
> > think they should be removed. If we were starting CC/PP again, then 
> > the way I would
do
> > it would be to start with a number of focused use cases, then use 
> > these
use
> > cases to check that there was sufficient complexity in the spec to 
> > meet
the
> > use cases but no more. At present, there is quite a bit of 
> > unnecessary complexity in the spec, but sadly it is not possible to 
> > address this in
the
> > current version. The hope is to get the current version out the 
> > door,
then
> > if there is sufficient interest, may be there will be a version 2.
> >
> > thanks, best regards
> >
> > Dr Mark H. Butler
> > Research Scientist                HP Labs Bristol
> > mark-h_butler@hp.com
> > Internet: http://www-uk.hpl.hp.com/people/marbut/
> >
> >
>
>
>

Received on Monday, 7 April 2003 04:35:55 UTC