cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Butler, Mark" <Mark_But...@hplb.hpl.hp.com>
Subject RE: DELI: Open source library supporting CC/PP and UAProf
Date Wed, 07 Nov 2001 11:55:20 GMT
Stefano, Ovidiu, thanks for the comments.

> RE: Cooperation, Visibility, Alphaworks

Maybe I ought to explain what my intentions are. I'm involved in the W3C
Device Independence Working Group who've just produced a principles document
that may be of interest to you - see
http://www.w3.org/TR/2001/WD-di-princ-20010918/. So one of my aims is to
demonstrate how ideas from the W3C translate into real technology. 

Secondly I'm concious although the CC/PP and UAProf specifications have been
around for a while, currently there is a "which comes first chicken or egg"
situation as browsers won't support it until servers do and vice-versa. So
DELI is an attempt to "seed" these standards. I'm hoping we have mutual
interests?

DELI is released under a BSD-type license so hopefully this shouldn't cause
any problems. One issue is whether we fork DELI to include it with C2 or it
exists as a plug-in. This might be advantageous as then it could be
incorporated into other projects e.g. Jetspeed. Any thoughts?  

> RE: Incorporating DELI

Stefano, Ovidiu, firstly thanks for your suggestions. Here's a quick summary
plus a few suggestions of my own. I'd be interested in any feedback /
comments / further suggestions.

> 1. (Stefano) a sitemap selector that connects to DELI

Yes, good idea.

> 2. (Stefano) produce DELITransformer that augments browser
> information to a particular namespace and adds it to the XML 
> file being processed.

Good suggestion. In an ideal world the appended profile would be in standard
profile serialisation rather than a special DELITransformer serialisation.
However this is difficult because a) it's hard to process XML serialisations
of RDF using XSLT e.g. attributes and elements are interchangeable b) the
current DELI implementation "cheats" as it takes the profiles and converts
them from an XML serialisation of RDF to it's own internal data structure.
This was necessary because UAProf uses order dependent resolution rules but
there is no concept of document order in RDF. Therefore implementing the
UAProf resolution rules using an RDF processor is difficult! It could
convert this back to XML, I'm just concerned about the efficiency of this
approach so I might have to rethink how DELI does merging / profile
resolution.  

Currently I'm thinking about solutions to these problems, but they are
dependent to the structure / syntax of CC/PP. One (controversial) way would
be for CC/PP and UAProf to use XML rather than RDF. Then you could just add
the resolved profile to the XML file being processed. Alternatively, there
may be a way of using a subset of the RDF XML serialisation syntax in CC/PP
so it is can be processed either via XML or RDF processors. Then DELI could
just use an XML processor (solving the resolution problem) and the profiles
could be queried by XSLT. Both solutions would require some changes to the
specs so would mean convincing the W3C / WAP Forum though.

Please note this isn't intended as a criticism of your suggestion - I'm just
thinking aloud as I'd be interested in hearing your thoughts? Unfortunately
both the CC/PP and UAProf working groups are trying to freeze their specs so
they aren't keen on discussing issues like this at the moment. 

> 3. (Ovidiu) take a similar approach to BrowserImpl.xml
> by passing browser information as a DOM tree. An XSLT 
> stylesheet can then use simple matching to obtain browser 
> capabilities. 

I had a quick look at this code before. Currently I'm not 
sure how to deal with multi-value parameters e.g. SEQs and 
BAGs. Any suggestions? 

> 4. (Ovidiu) Using approach 3) provide some standard stylesheets that can
transform (a subset of) XHTML to devices using profile information.

Yes, although obviously best to get 3) to work first.

Then my suggestions are:

5. Provide a simple way of performing conditional inclusion in the XML or
XHTML content based on the profile information. So instead of having an
image with alt text, you could multiple versions of resource associated with
profile conditionals indicating when each version should be used. Morphis
uses an approach a bit like this in its WAX language (see
http://www.morphis.org). For example you might want to express:

if small screen (phone) then include nothing
if voice browser then include voice_menu (only read if user presses hash)
if medium screen (pda) then include icon_menu
if large screen (pc) then include full_menu

Note here devices are not simply split into "device classes" (e.g. phone,
pda, PC) rather we are providing alternates that can be selected using
multiple "axes of negotiation" i.e  screen size, sound capabilities, image
capabilities, input capabilities etc. Axes of negotiation is a concept taken
from the HTTP/1.1 spec. This would demonstrate some of the device
independence techniques I've been thinking about. 

6. Add an image transcoder that can use profile information e.g. adapts the
image based on mime-type and screen size information. 

> Stefano writes:
> Well, if you want to do what you just proposed to integrate 
> Mark's work, I'll be +1 on that.

I've got time to put in the integration as well, but I'm a totally newbie to
Cocoon-dev so any advice is greatly appreciated.

cheers

Mark Butler
http://www-uk.hpl.hp.com/people/marbut/
Research Scientist
HP Labs


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message