Re: FW: CC/PP Structure and Vocabularies last call working draft - a couple 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 13:30:27 UTC