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 Friday, 4 April 2003 14:11:52 UTC