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 Wed, 07 Nov 2001 09:47:24 GMT
Ovidiu Predescu wrote:
> 
> On Mon, 05 Nov 2001 23:36:16 +0100, Stefano Mazzocchi <stefano@apache.org> wrote:
> 
> > Ovidiu Predescu wrote:
> > >
> > > Hi,
> > >
> > > This is very good stuff, Mark! I've looked at it briefly and I like it.
> >
> > Now, don't you love it when big companies people find a way to
> > cooperate on an open source list? :)
> 
> :)
> 
> Actually Mark and I have been talking about this for quite some
> time. Still your point is still valid, as many people tend to think of
> big companies as a place where anybody knows what everybody else is
> doing in the company. The situation is very different, in fact, just
> like in real life, you usually don't have much visibility on what
> others are doing unless you communicate with people.

Oh, yes, I know. In fact IBM alphaworks was done exactly for that and I
think it was a good move (alphaworks, despite the fact you can download
stuff and even the source sometimes, it's not about opensource but it's
all about internal visibility)

Anyway, I'm very happy to have this CC/PP discussion here!

> > > One way would be to expose it to XSLT, so that people can take
> > > advantage of device capabilities when generating pages.
> >
> > Yeah, that could be a good choice, or another one (without touching
> > XSLT extensions which are not portable) would be to have a
> > DELITransformer that augments browser information into a particular
> > namespace and adds it to the end of the XML file being processed.
> 
> I wasn't thinking of using XSLT extension functions. Take a look at
> how the current browser component deals with the browser information
> which is described in BrowserImpl.xml. It essentially takes the
> browser information and passes it as a DOM tree using an XSLT
> parameter. An XSLT stylesheet can then use simple matching on this
> parameter to obtain browser capabilities.
> 
> As an example, suppose the browser is a Nokia cell phone. The
> 'ua-capabilities' XSLT parameter would contain a DOM tree which is the
> equivalent of the following XML document:
> 
> <browser xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405">
>   <user-agent>Nokia</user-agent>
>   <mime-type>text/vnd.wap.wml</mime-type>
>   <formatter-type>text/wml</formatter-type>
>   <has-accesskey/>
>   <has-wtai-add-phonebook/>
>   <binds-call-to-send>vnd.up.send</binds-call-to-send>
>   <prf:WmlDeckSize>1400</prf:WmlDeckSize>
> </browser>
> 
> This XML document becomes the value of the 'ua-capabilities' parameter
> in an XSLT stylesheet. You can then write a stylesheet like this:
> 
> <xsl:param name="ua-capabilities"/>
> 
> <xsl:template name="phone">
>   <xsl:if test="$ua-capabilities/binds-call-to-send">
>     <!-- Generate markup to automatically bind the "send" button on
>     the cell phone to call the phone number -->
>     ...
>   </xsl:if>
> </xsl:template>
> 
> I've implemented this sometime last year for C1, and Dims ported it to
> C2.

Got it. Makes perfect sense.
 
> > > The next step from here would be to come up with a set of
> > > stylesheets for XHTML to automatically generate the right markup
> > > for the requesting device.
> >
> > That's where selectors kick in.
> 
> I'm not sure the selectors solve the complete problem. They are really
> good when dealing with different types of markup languages, but for
> small variations in the functionality of the same category of devices,
> something at the XSLT layer works better IMO.
> 
> Imagine all the WML browsers out there, each with its own variation in
> the implemented WML features. Having multiple XHTML->WML stylesheets,
> one per device, is very difficult to maintain. If you have only one
> set of XHTML->WML stylesheets which contain all the possible
> variations, it's probably easier to deal with.

Very good point.
 
> > > Are there any other ways or places where we can take advantage of it?
> >
> > Hmmm, I can't think of any... but I'm sure that as soon as we
> > integrate it, people will start using it for ways we didn't think
> > about. but again, open to suggestions.
> 
> Yes, I agree.

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

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