Re: Technical Report on Capability Classes

Hi Mark,
 
> If I understand your comments correctly you think there is a problem with my
> approach.
 
No, my comments discussed the capability class approach and the problem of the content negotiation in general. I didn't discussed your proposal in a well determined target context (such as handling CC/PP writhing Apache within style sheets, etc.) 
 
>I'm interested in your position also, but it would be helpful if you could
>clarify?
 
I thought that my comments were clear, unfortunately they weren't :-). 
As you know, I work also in the same problem of the content negotiation in heterogeneous environments. Our objective is to resolve that problem in a practical environment that contains a wide diversity of clients (PDA, PCs, Laptops, phones, etc.). The CC/PP model was used to describe the client capabilities but also to describe other elements such as the document profile, the server capabilities, etc.
 
Some clarifications about our approach can be found in http://opera.inrialpes.fr/people/Tayeb.Lemlouma/mainIndex.htm section research in progress.
 
If I can give a quick resume of my last minor comments about the proposed capability class approach (that responds sure to your needs), I can say that:
 
1- In my opinion, predefining classes of devices can not cover all the kind of devices and pose the problem of the abstraction level used during the definition of the classes. The definition of the classes influences on the content negotiation task this is why that point must be taken into account to ensure an efficient deliverance of a content that matches well the characteristics of the end user.   
2- Server adaptation can cover more than just XSLT adaptation mechanisms, but since you target a well determined context your approach can be efficient.
3- My last comment were about your constraints definition in terms of conditional relations. More exactly about lessthan and greaterthan between dimensions. The two conditionals are not -semantically- opposite and consequently some dimensions can be incomparable. I think that constraints definition plays a principle role in the content negotiation (the server will try to resolve the client constraints in order to deliver an adapted content) this is why a big effort must be made on this point.
 
Concerning our approach and in addition to the URL that I have given above; actually we are written a paper for the IEEE which discuses the NAC (Negotiation and Adaptation Core) architecture and which contains some interesting results (adapted content is delivered according to different profiles...). I'll send you the paper when it will be finished.  
 
Finally, I'd like to note twice that I found your report very well written and very benefit in my work. 
    
Regards.
 
Tayeb* 
----------
Tayeb Lemlouma
http://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html
Opera project
National Research Institute in Computer Science and Control (INRIA Rhône-Alpes, France )
Office B213, phone (+33) 04 76 61 52 81, Fax (+33) 04 76 61 52 07.

----- Original Message ----- 
From: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
To: "'Tayeb Lemlouma'" <Tayeb.Lemlouma@inrialpes.fr>
Cc: <www-mobile@w3.org>
Sent: Tuesday, April 23, 2002 6:31 PM
Subject: RE: CC/PP 


> Hi Tayeb,
> 
> Thanks for your comments on my report. Please could you explain them
> further? The reason I came up with the capability class proposal is I need a
> mechanism of being able to use CC/PP within Apache Cocoon, specifically
>  
> i) within stylesheets
> ii) within the sitemap
> iii) in image transcoders
> 
> If I understand your comments correctly you think there is a problem with my
> approach. However I'm not sure what that problem is? Perhaps it would help
> if you made your comments constructive i.e. can you propose how to fix my
> approach or any alternative approaches?
> 
> So far I've had feedback from Takashi Nishigaya (Fujitsu) and Luu Tran
> (Sun). To paraphrase the comments, Takashi Nishigaya preferred an RDF
> approach to representing the device capabilities required by a document,
> similar to my report on content negotiation. Luu Tran on the other hand
> takes the view that CC/PP information will be used primarily by Java
> programs, rather than in XML configuration files or stylesheets so a
> mechanism like capability classes is less important than the Java API. I'm
> interested in your position also, but it would be helpful if you could
> clarify?
> 
> thanks, best regards
> 
> Mark H. Butler, PhD
> Research Scientist                HP Labs Bristol
> mark-h_butler@hp.com
> Internet: http://www-uk.hpl.hp.com/people/marbut/
> 
> > -----Original Message-----
> > From: Tayeb Lemlouma [mailto:Tayeb.Lemlouma@inrialpes.fr]
> > Sent: 23 April 2002 11:35
> > To: Butler, Mark
> > Cc: w3c-di-wg@w3.org; w3c-ccpp-wg@w3.org; www-mobile@w3.org
> > Subject: Re: CC/PP 
> > 
> > 
> > Hi Mark,
> > I read you report on capability classes and found it very 
> > interesting. Here
> > are some
> > comments:
> > 
> > - Content adaptation based on XSLT is interesting in structural
> > transformation
> > (e.g. XHTML to WML, HTML to SMIL, etc.) but there is another kind of
> > adaptation which
> > is very important and can be seen as the complementary of structural
> > transformations
> > which is media resources transformation. A simple example to 
> > see that is the
> > transformation of HTML to WML. In this case, to achieve the adaptation
> > properly, media
> > resources used inside the original document (HTML) must also 
> > be transformed,
> > for
> > instance JPEG to WBMP images.
> > 
> > - The initial definition of classes of devices is benefit but not
> > sufficient.The number
> > of the combination of ATOMIC characteristic properties may be 
> > infinite. This
> > implies
> > that the classes definition will, in all the cases, negligee 
> > some kind of
> > devices.
> > Further more, we can't envisage all the possible kind of 
> > constraints of the
> > existing
> > set of devices and also for future devices.
> > 
> > - Devices may be very different, or have just some little 
> > difference in
> > characteristics
> > properties. This underlines the problem of the abstraction 
> > level used in the
> > definition
> > of the capability classes. Note that due to just one 
> > difference of atomic
> > characteristics
> > between two devices, the server may have to deliver two 
> > contents which are
> > completely
> > different.
> > 
> > - Axes of negotiation depend to the detailed level of the 
> > user constraints
> > declaration
> > and the capability of the server either by available XSLT 
> > style sheets or
> > other
> > adaptation methods (scripts, programs, etc.). The number of 
> > the required
> > adaptation
> > methods (XSLT sheets for instance) depends so to how methods 
> > were designed.
> > In the case
> > of XSLT we can have parameterable and composite style sheets 
> > which can takes
> > into account
> > more than one predefined device class.
> > 
> > - A little comment concerning Section 4:
> > I think that the conditional "lessthan", for boxes, is not 
> > the opposite of
> > the
> > "greaterthan" conditional (if B1 isn't lessthan B2, this 
> > doesn't implies
> > that B2 is
> > greaterthan B1). This may causes that there is a set of boxes 
> > that are not
> > comparable and
> > consequently we can negligee some class of devices using the proposed
> > conditional.
> > ----------
> > Tayeb Lemlouma
> > http://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html
> > Opera project
> > National Research Institute in Computer Science and Control (INRIA
> > Rhône-Alpes, France )
> > Office B213, phone (+33) 04 76 61 52 81, Fax (+33) 04 76 61 52 07.
> > 
>