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.
>

Received on Tuesday, 23 April 2002 12:32:42 UTC