W3C home > Mailing lists > Public > www-mobile@w3.org > September 2001

Forward: [Moderator Action] RE: Any CC/PP App servers in the market

From: Kazuhiro Kitagawa <kaz@w3.org>
Date: Tue, 04 Sep 2001 10:30:58 +0900
Message-ID: <87zo8blp2l.wl@CF-L1.w3.mag.keio.ac.jp>
To: www-mobile@w3.org

attached mail follows:



> Our problem is time - the working group is rapidly diminishing in number
and committment with the
> finishing-up of the spec being simultaneous with a downturn in the
industry.

hum, too bad.  i think (the idea of) cc/pp is right on.  i am in the middle
of determining if i should extend our product to support cc/pp natively both
for device and user profiles maybe for content negotiation.  still not sure
if i would implement the whole cc/pp spec though.

ceo


> -----Original Message-----
> From: www-mobile-request@w3.org [mailto:www-mobile-request@w3.org]On
> Behalf Of Johan Hjelm
> Sent: Wednesday, August 15, 2001 9:23 PM
> To: Butler, Mark
> Cc: 'cafe babe'; www-mobile@w3.org
> Subject: Re: Any CC/PP App servers in the market
>
>
> Thanks Mark for those good comments. Our problem is time - the
> working group is
> rapidly diminishing in number and committment with the
> finishing-up of the spec
> being simultaneous with a downturn in the industry.
>
> We are trying to wrap up the spec to go to candidate
> recommendation now, and
> then we will recharter the group to restart the work (I know, I
> have been saying
> that for a while now). One reason is for that is to do the protocol work
> properly - the numerical namespaces in the HTTP header comes from the HTTP
> Extension Framework, and that was actually more or less a
> political decsion. It
> would have been much cleaner to do a new HTTP header, but we were
> not allowed to
> do so at the time. So modifications of the servlets is as well to
> put off until
> then.
>
> We have not been tracking resources on our web pages for the
> simple reason that
> there has only been a couple, but now there are at least four
> publicly available
> ones, so that is something we should do.
>
> One more comment, about device classes: It works fine as long as
> you can assume
> that devices do not diverge from a class. But as soon as they do,
> you have a
> problem. I would expect heuristics to be written to determine
> that there is an
> 80% fit, and that is fine (but someone has to determine WHICH
> 80%, and declare
> it!). To be sure, if your device conforms to a class (who determines
> conformance?), you can always send an override for the little
> extras that you
> have built in. But there has to be a full description of the
> class somewhere.
>
> Vladimir, would you mind sharing your device classes and
> definitions with us? I
> am sure it would be useful.
>
> Johan
>
> "Butler, Mark" wrote:
>
> > As far as I know there are no CC/PP enabled app servers on the market -
> > current servers use the User-Agent string and then often use their own
> > device capability database. For an example of this, see the
> device.xml file
> > in the Morphis open source device transcoder
> (http://www.morphis.org/) or
> > the BrowserImpl.xml file in the Cocoon 2 framework
> > (http://xml.apache.org/cocoon).
> >
> > Furthermore as far as I am aware, no-one seems to have
> considered whether
> > the proposed CC/PP (http://www.w3.org/TR/NOTE-CCPPexchange) and UAProf
> >
> (http://www1.wapforum.org/tech/terms.asp?doc=WAP-248-UAProf-200105
> 30-p.pdf)
> > protocols will be compatible with the current HTTP servlet API. I'm
> > currently trying to determine whether current app servers can use the
> > proposed CC/PP and UAProf protocols or whether this will
> necessitate changes
> > to the base servlet API. Personally I think it would be better to use a
> > protocol that is compatible with the javax.servlet.http API,
> and derive a
> > new API(s) from that specifically for CC/PP and UAProf.
> >
> > Specifically current servers such as Tomcat will respond to some CC/PP
> > requests. There are two problems: Firstly the HTTPex numerical namespace
> > seems to add unnecessary complexity - perhaps someone from the
> CC/PP working
> > group could explain the rationale behind this? Secondly
> including carriage
> > returns in the XML file associated with a profile-diff causes
> problems with
> > the current servlet API. For example if I send the following
> CC/PP request
> > to a simple HTTP request snooping servlet on a Tomcat server
> >
> > GET /ccpp/headers/index.cgi HTTP/1.1
> > Host: localhost
> > Opt: "http://www.w3.org/1999/06/24-CCPPexchange"; ns=19
> > 19-Profile: "http://www.aa.com/hw", "http://www.bbb.com/sw",
> > "1-uKhJE/AEeeMzFSejsYshHg=="
> > 19-Profile-Diff-1: <?xml version="1.0"?>
> >  <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
> >              xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
> >              <Description ID="SoftwarePlatform" PRF:Sound="On" />
> >          </RDF>
> >
> > Then I can successfully retrieve the file from Tomcat once, but
> subsequent
> > retrievals or not always possible as Tomcat reports
> >
> > Parse error, missing : in
> > mlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
> >
> > This problem can be avoided by omitting carriage returns in the enclosed
> > XML. However this requirement is not mentioned in either the CC/PP and
> > UAProf protocol specs! The request above does not cause a
> problem for Apache
> > with a CGI HTTP request snooping Perl script, but I suspect
> other servers
> > using the servlet API will have similar problems.
> >
> > Of course once your server has got the profile, then there's
> the problem of
> > what to do with it! This also needs "further development" just like
> > vocabularies. Stuart Lewis, a student at University of Wales at
> Aberystwyth
> > (sdl@aber.ac.uk) has a project report that discusses this. I've just
> > finished a technical report that investigates implementing
> HTTP/1.1 content
> > negotiation for CC/PP and UAProf using the JENA RDF API (see
> > http://www-uk.hpl.hp.com/people/bwm/rdf/jena/index.htm) that should be
> > published externally this month. Another comment to the CC/PP
> working group:
> > please could you start keeping track of these resources in a
> similar way to
> > the RDF working group?
> >
> > Once a servlet API is defined, I think the next step would be
> to add CC/PP
> > support to open-source frameworks like Cocoon, Struts, and
> Jetspeed (see my
> > technical report at http://www-uk.hpl.hp.com/people/marbut/ for
> more details
> > of how these frameworks can be used for device independence).
> They already
> > try to address the problem of content adaptation, so it makes
> sense to use
> > them to demonstrate how CC/PP can be used to provide content to multiple
> > devices.
> >
> > Incidentally feedback on my comments on HTTPex, servlet APIs
> etc from the
> > CC/PP working group is welcome!
> >
> > Mark H. Butler
> > HP Labs Bristol
> >
> > -----Original Message-----
> > From: cafe babe [mailto:cafe_babe@hotmail.com]
> > Sent: 15 August 2001 16:34
> > To: www-mobile@w3.org
> > Subject: Any CC/PP App servers in the market
> >
> > Just curious to know, are there any commercially available
> Application/Web
> > servers in the market that are capable of using the CC/PP
> information in a
> > client request to generat customized content for a client.
> > I remember seeing some CC/PP classes in Jigsaw the W3C web server. BEA
> > Weblogic mentions something about device profiles but I am not
> sure if it
> > uses CC/PP for content customization.
> > Quite a few  Application server vendors(Oracle,IBM,BEA to name
> a few)  in
> > the msrket today say that they are capable of customizing
> content for all
> > different kinds of devices(phones,PDAs,TVs etc) and that they
> are extensible
> > to support any new devices in the future. What I am not clear is that do
> > they mean that they can support any device that can render
> XHTML/HTML/WML,
> > in whuch case the HTTP "Accept" header would be sufficient, or they mean
> > that they can use a CC/PP kind of mechanism to do further customization
> > based on other parameters like display size, media support etc.
> > Inputs on this would be really appreciated.
> > Thanks
> >
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
>
> --
> ++++++++++++++++++++++++++++++++++++
>   Johan Hjelm, Senior Specialist
>      Ericsson Research Japan
>
>   Read more about my recent book
> http://www.wireless-information.net
> ************************************
>
>
Received on Monday, 3 September 2001 21:31:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 13:00:00 GMT