RE: Technical Report on Capability Classes

Hi Luu

Some replies on your comments - what do you think?

> o Terminology: you use "content specialisation" but the DI 
> Principles document 
> uses "content adaptation".

My use of "content specialisation" was deliberate. I use it to refer
collectively to four subclasses "content adaptation", "content selection"
and "content generation", "content transcoding":
- content adaptation is stylesheets
- content selection is content negotiation
- content generation is JSPs
- content transcoding is transcoding images, streaming media, audio etc. 

I'm not sure how the DI document distinguishes between these methods. I'll
take a look and see if I can resolve the terminology issue. Terminology is
always problematic!


> o It seems to me that capability classes is a useful 
> abstraction for delivery 
> systems that use XSLT, but I'm not sure that this abstraction 
> should place any 
> additional requirements on CC/PP, UAProf, or new 
> vocabularies. The XSL 
> conditional expression limitation of certain UAProf datatypes 
> seems to be merely 
> a result of XSL's limitations, not the datatypes themselves.  
> Isn't it possible 
> for an alternate content adaptation mechanism, e.g. JSP, to 
> handle UAProf's 
> dimension datatypes and version numbers more easily?  In my 
> opinion, XML makes 
> for a poor programming language, and XSL is therefore 
> difficult to use for 
> anything beyond simple transformations.

I don't think capability classes should place requirements on CC/PP, so I'm
sorry as I seem to have caused some confusion. 

However I do think CC/PP should specify a standard set of data types and a
standard processing model. I think this is a requirement so that any profile
query method (of which capability classes is an example) can be guaranteed
to process any CC/PP vocabulary. So I'm not saying this because of
limitations with XSL (which I would agree with you on), I'm saying it
because I think it is core CC/PP. Where CC/PP uses data types that are
commonly available in programming languages life is easy as we just use the
ones we already have available. Where we need to use different datatypes I
think we need to define some operators. Even if we are manipulating profiles
at an API level rather than a query level(e.g. capability class) I think
such operators would be useful. 

So my questions for you are:
i) do you think a common processing model is required? To clarify, by
processing I mean profile resolution and query. 
ii) do you think CC/PP requires a standard closed set of data types?
iii) where a data type is not a standard data type found in the API
language, do we need to define appropriate operators?

However I want to distinguish between some of the data type examples I have
used: for example I think version numbers should be a standard CC/PP data
type. In fact this was raised at last call by Aaron Schwartz. Dimensions on
the other hand are a horrible bodge (bad engineering decision) but because
CC/PP has to be backward compatible with UAProf we have to consider them.
Another key data type for CC/PP but which is not currently distinguished in
the schema is enumeration.

> o I gather from section 5 that you're suggesting that 
> capability classes should 
> be considered in developing new CC/PP vocabularies.  I think 
> CC/PP vocabularies 
> should be constrained to dealing with describing "what" 
> consitutes the delivery 
> context (it's form), rather than infringing on the realm of 
> "how" to deal with a 
> particular delivery context (it's function). Granted, 
> incompatible processing of 
> delivery context information is bad, and therefore the 
> semantics behind delivery 
> context attributes should be clear.  But I think the line 
> should be drawn at 
> implying how the attributes should be handled by specifying 
> what the attributes 
> mean, rather than specifying a mechanism for handling the attributes.

I think this is a similar confusion to above - what I meant to advocate was
"this indicates CC/PP needs a standard processing model" not "capability
classes is that processing model". 

Here I was referring to the problem with UAProf where they define what
attributes mean but not the attribute values - so there is a danger people
might useful different values to mean the same thing or the same to mean
different. Does this fit in with where you think the line should be drawn?
For example if a attribute uses an enumeration I'd like to see

attribute name
attribute meaning
the set of possible values with the meaning of each of set member

or if an attribute is a rational number I'd like to see

attribute name
attribute meaning
appropriate units if any
minimum value
maximum value

etc

Does this seem reasonable to you?

> o I'm not sure you've mentioned the case where the same set 
> of XSLs are reused 
> for all or a large subset of a site's XML content.  In such a 
> case, the XSLs are 
> related to delivery contexts and the XMLs are mostly 
> independent of delivery 
> context.  This often necessitates some common interface or 
> agreement between the 
> XML and XSL authors.  In this scenario, it would seem that 
> capability classes 
> would need to permeate throughout the XML and XSL authoring processes.

Well, one of the advantages I see with capability classes is you define them
once, then can re-use them in any of the XSLs on your site. This is useful
as the job of knowing about devices and vocabularies can be assigned to a
developer, then the content author only has to know about the capability
classes in order to right content. 

However, if XSLs are reused as you describe, this reusability is less
important. Here the content authors are working at the XML level whereas the
developers are working at the XSL level. I can't see a problem with this and
capability classes though - unless I'm missing something?

I was quite interested to see Fujitsu's approach as I think there are many
similarities between their approach and capability classes. I think that
this similarity provides evidence that there is something potentially useful
here, although I don't think we have the final solution yet. For example
Fujitsu have tried to based their approach on RDF, whereas I adopted XML for
brevity after experimenting with RDF approaches to content negotiation. 

please let me know what you think and thanks again

Mark H. Butler, PhD
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Tuesday, 30 April 2002 11:29:08 UTC