Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200111072118.fA7LIDB25093@orion.rgv.hp.com>
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
Cc: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: Re: DELI: Open source library supporting CC/PP and UAProf 
In-Reply-To: Your message of "Wed, 07 Nov 2001 11:55:20 GMT."
             <5E13A1874524D411A876006008CD059F031A12F3@0-mail-1.hpl.hp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 07 Nov 2001 13:18:13 -0800
Sender: ovidiu@orion.rgv.hp.com

On Wed, 7 Nov 2001 11:55:20 -0000 , "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com> wrote:

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

That's right ;-)

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

I think Cocoon should be able to make use of DELI the same way is able
to make use of other technologies. We should be able to call the API
directly in our code, instead of relying on DELI being deployed as a
servlet.

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

As I said in a previous email, XSLT processors allow you to pass DOM
trees as values of parameters. As a result, you can pass the SEQs and
BAGs as they are to the XSLT processor.

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

Option 3 works already, it's implemented by BrowserImpl.

> 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

I am no longer convinced that the same presentation front-end can be
used to generate the pages for media rich and small devices. The feel
of a small device is too different, and the navigation is very
different from media rich browsers. I now think that one should write
two different presentation layers, one for small devices and one for
media rich devices. The layer for small devices is then able to
generate the right markup for each device, specifically adapted to the
requesting device.

As far as the developer of the application is concerned, he/she should
use a language that expresses the content of the app, rather than how
it looks. Something like the stylebook or Simplified DocBook would
make a lot of sense. The navigational part could be provided by
something like XForms, although right now it's a bit unclear to me how
these would blend together.

Cocoon would then come and present the information, setup the
necessary navigation for the particular device. Cocoon can also take
care of images and other media types.

I'm not sure whether this is better than coming up with yet another
XML language, but to me WAX is yet another presentation language. And
I think this is the wrong approach, because it focuses on the
presentation rather than content.

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

I think one still needs to split the devices in classes based on the
markup language they use. Or maybe not, with a careful design of the
stylesheets.

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

This makes a lot of sense.

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

The more heads, the better ;-) I'm sure there's enough to work for all
of us.


Regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.rgv.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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