cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: DELI: Open source library supporting CC/PP and UAProf
Date Thu, 08 Nov 2001 00:16:42 GMT
"Butler, Mark" wrote:
> 
> Stefano, Ovidiu, thanks for the comments.

Well, we have to thank you.
 
> > 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.

...and that some ideas from this list translate into W3C WDs :)
 
> 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?

Yep.
 
> DELI is released under a BSD-type license so hopefully this shouldn't cause
> any problems. 

Great. But you should sign the paper that give the ASF copyright of the
code (we can talk about that privately afterwords).

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

I would place it in Cocoon first and maybe then move it into an avalon
component or in its own subproject if found necessary.
 
> > 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.

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

Controversial, but very useful since RDF and XSLT don't mix at all!

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

I'm overwelmed! Big time! But you definately look like a guy that knows
what he does so, I'm definately +1 in accepting your code donation
overhere and propose you for commit access so that you can take care of
that yourself. (I suspect not many people here would be able to do it
without the knowledge you already have about the problem).

So, guys, place your vote: do you want to accept Mark donation and have
him help us with this directly giving him commit access?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

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


Mime
View raw message