cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: DELI: Open source library supporting CC/PP and UAProf
Date Tue, 06 Nov 2001 23:59:28 GMT
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.

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

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

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


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


Mime
View raw message