Hello all,

My name is Dominique Hazael-Massieux, and I work for the W3C in the
Mobile Web Initiative [1].

Among other things, I'm the co-Chair of the Mobile Web Test Suites
Working Group:
http://www.w3.org/2005/MWI/Tests/

We have started last week a call for contributions to build a test suite
that reflects the needs from the Mobile Web authors community:
http://lists.w3.org/Archives/Public/public-mwts/2007Jul/0020.html

Basically, the idea is that we accept test cases that illustrates usage
of Mobile Web technologies in order to evaluate whether existing user
agents support them.

Later on, once we have received enough test cases, we'll release these
test cases into an organized test suite, and collect results from
anybody interested in testing their mobile devices on it.

(we have already set up a test harness that allows to do this with a few
existing W3C test suites:
http://www.w3.org/2007/03/mth/harness )

I think this project has a lot of common with what is usually discussed
on this list, and more generally speaking, dealt with in the WURFL
project; in particular, I read the recent discussions on the list to try
to define various levels of support for XHTML in existing browsers,
which I think our open mobile web test suite could help assess. In other
words, I think our system could be used to collect the raw data about
the support for a particular set of features, and these data could be
then reused in a more abstract/useful way in WURFL.

I guess the purpose of my messages is to invite you all to submit test
cases to our system, and/or discuss any questions you may have on it, or
any suggestions/clarifications you would like.

The submission interface is at:
http://www.w3.org/2005/MWI/Tests/Open/submit and we have defined a set
of submissions guidelines at:
http://www.w3.org/2005/MWI/Tests/Open/submission

(the current system is somewhat experimental, and may impose more
limitations than necessary, so please feel free to let me know about any
issues you would encounter with it should you choose to use it)

Thanks for your time,

Dom

1. http://www.w3.org/Mobile/

Hi Ron,

   I want to thank you so much for responding to my post.

   We've developed a service for pushing out video and have been getting a lot of
interest from agencies, political organizations, and more.

   Our method - so far - has been to use a lowest common denominator.

   Here for instance is our generic code (below) that we flip around depending on
the push.

   We can hit many devices with this method via sms.  However, I am going to look
into your suggestion.

   Are you in the US? Do you have a company and do you consult?

   thanks

   Brian McLane

   our site is www.iprogram.tv



   <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="index" title="Index">
<p>
Here's a clip of Atil Kutoglu from Bryant Park:
<br/>
<a href="rtsp://PowerHost.QT.PowerStream.NET/002/00293/atilx.3g2">Click here for
3G2</a>:
<br/>
<a
href="Click'>http://powerlink.powerstream.net/002/00293/atilx.asx">Click here
for Windows Mobile</a>
:
   <br/>
   <a
href="Click'>http://progressive.PowerStream.NET/002/00293/2007.06.04/atilx.3gp">\
Click here for Berry, VZW, T-Mobile</a>

<br/>
<a href="Special'>http://iprogram.tv/europa/coupon.jpg">Special Offer</a>:
   <br/>
<a href="Sign'>http://iprogram.tv/wap/wregistration.aspx">Sign Up For This
Alert</a>:
   <br/>
<a href="Go'>http://www.iprogram.mobi">Go to WAP Site</a>:
   <br/>
<a href="Remove'>http://iprogram.tv/wap/optout.aspx">Remove Me</a>:
</p>
</card>
</wml>

Ron Mandel <ronanmandel@...> wrote:
           So, first off, why would you want to deliver WML to this device? It's
got the Openwave 6.2.3 browser on it and does a pretty decent job of
handling XHTML-MP and CSS.

That said, if WML is not rendering on the device, have you tried
sending compiled bytecode (wmlc)?

Ron

--- In wmlprogramming@yahoogroups.com, "brisontheweb"
<brisontheweb@...> wrote:
>
> Any breakthroughs on how to get a WML to show up on a Chocolate or
> other Verizon Wireless 3G devices?
>
> Thanks
>






---------------------------------
Pinpoint customers who are looking for what you sell.

[Non-text portions of this message have been removed]

Gents,

I have a simple question:

How does one account for scrollbars?

More specifically most of WURFL just lists the # of dots a device has, not what
happens when you actually try to render a page with content. Many devices draw a
scrollbar, and oops, then the 176-wide image doesn't fit, so let's add a
horizontal scrollbar...

Removing 10 pixels from all devices is a sortof-maybe solution but it doesn't
look pretty on non-scrollbarred devices.

In PRINCIPLE the resolution_width seems to cater to usable width but I find that
often it doesn't. Is there any hope we can improve this somehow?

I sought the advice of a number of Flash Lite professionals around about
how to best support Flash lite devices in WURFL.
The answer is the result that I present here:

the old "flash_lite_*" capabilities in the "image_format" group are
gone, wile a new "flash_lite" group has been introduced.

       <group id="flash_lite">
         <capability name="flash_lite_version" value=""/>
         <capability name="fl_wallpaper" value="false"/>
         <capability name="fl_screensaver" value="false"/>
         <capability name="fl_standalone" value="false"/>
         <capability name="fl_browser" value="false"/>
         <capability name="fl_subcld" value="false"/>
       </group>

flash_lite_version can be "",1_0,1_1,1_2,2_1 or whatever the future will
bring.
The other capabilities represent Flash Lite applications that may or may
not be available on a given device.
There was some flash_lite information about non-Nokia devices in the old
version of the WURFL.
That info has been retained by adding:

       <group id="flash_lite">
         <capability name="flash_lite_version" value="1_1"/>
       </group>

Aditionally, I also made sure that iMode devices were assigned some
minimalistic FL capabilities too (in order not to leave asian phones down).

Credits for this go to:

  Alessandro Page (AKA Biskero) for creating a repository of FFlashLite
info called FLuaprofile.xml:

http://www.biskero.org/?p=1169
http://www.biskero.org/fl/fluaprofile.xml

and to:

  Jonathan Arnold, of Break Design (www.breakdesign.com) for turning
Alessandro's work into a WURFL patch file (which also contained 5
devices which were not in the WURFL originally).
A round of applause for these two guys.
I would also like to acknowledge  Stefan Wessels of Break Design for
getting it started.

  From now on, developers can leverage existing WURFL APIs and the
repository to understand if a device knocking at your portal support FL
or not.

Enjoy

Luca

PS: I am still working on the patcher from Sergey, Steven and Rainer. I
just felt it was right to give Flash Lite a fast track to developers...

The capability namespace is flat. So once a capability is defined, its
value can theoretically be defined for any device.
Anyway, the impact is not so big. Adding the capabilities in generic and
in another 6 or 7 containing nokia device, I have covered pretty much
every Nokia device. This bit of info seems relevant for the Flash Lite
community. BTW, you can hold your breath about a big Flash lite update
on its way...

Luca

Alejandro Guerrieri wrote:
> Wouldn't make more sense to implement it at the generic device level, maybe
> as "brand_series" and "brand_edition" ?
>
> I mean, putting capabilities that are specific to a particular brand doesn't
> make a lot of sense IMHO, but having a set of capabilities flexible enough
> to accomodate for different manufacturer "series" or "edition" does.
>
> I'd then go for an approach where each "series" have a common ancestor (like
> nokia series actually) and then I'd set this capability on that node.
>
> Just my 2 cents.
>
> Regards,
>
> Alejandro Guerrieri
>
> On 8/5/07, Luca Passani <passani@...> wrote:
>
>>   People,
>>
>> I was suggested an enhancement which made a lot of sense and required
>> little effort to implement. So I suggested to go ahead and implement it
>> without further ado:
>>
>> <device user_agent="Nokia 90 Developer Platform 2.0"
>> fall_back="nokia_generic_series80_dp20" id="nokia_generic_series90_dp20">
>> <group id="product_info">
>> <capability name="nokia_series" value="90"/>
>> <capability name="nokia_edition" value="1"/>
>> </group>
>>
>> If anyone strongly objects to this, please speak up now.
>>
>> Thanks
>>
>> Luca
>>
>>
>>
>>
>
>
>
>

Wouldn't make more sense to implement it at the generic device level, maybe
as "brand_series" and "brand_edition" ?

I mean, putting capabilities that are specific to a particular brand doesn't
make a lot of sense IMHO, but having a set of capabilities flexible enough
to accomodate for different manufacturer "series" or "edition" does.

I'd then go for an approach where each "series" have a common ancestor (like
nokia series actually) and then I'd set this capability on that node.

Just my 2 cents.

Regards,

Alejandro Guerrieri

On 8/5/07, Luca Passani <passani@...> wrote:
>
>   People,
>
> I was suggested an enhancement which made a lot of sense and required
> little effort to implement. So I suggested to go ahead and implement it
> without further ado:
>
> <device user_agent="Nokia 90 Developer Platform 2.0"
> fall_back="nokia_generic_series80_dp20" id="nokia_generic_series90_dp20">
> <group id="product_info">
> <capability name="nokia_series" value="90"/>
> <capability name="nokia_edition" value="1"/>
> </group>
>
> If anyone strongly objects to this, please speak up now.
>
> Thanks
>
> Luca
>
>
>



--
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/
LinkedIn: http://www.linkedin.com/in/aguerrieri


[Non-text portions of this message have been removed]

Ken, either I misunderstood your point or Francis is right. A carrier
can have the Openwave gateway and still support devices with browsers
from different manufacturers

Luca

Francis Li wrote:
> Bell Mobility using Teleca/Obigo was a guess (hence the "?"!), but data
> I'm getting from HTTP headers suggest otherwise.  Is it not possible for
> a handset to be using the Obigo browser while the operator uses the
> Openwave gateway?  I don't think one implies the other.  Here's an
> example of a Bell Mobility request from the Samsung M610 that I've
> received:
>
>   accept = text/vnd.wap.wml, text/css, text/ecmascript, image/png,
>   image/gif, image/jpeg; q=0.5, image/x-bmp; q=0.3, image/vnd.wap.wbmp;
>   q=0.2, audio/mid, audio/midi, audio/qcelp, audio/vnd.qcp,
>   audio/vnd.qcelp, audio/aac, audio/mp3, audio/x-wav, audio/x-wave,
>   audio/mpeg3, audio/mpeg, audio/mpg, audio/amr, application/x-pmd,
>   application/x-cmx, application/x-pmd, audio/m4a, audio/mp4,
>   audio/3gpp, audio/3gpp2, audio/mp4a-latm, video/3gpp, video/3gpp2,
>   video/mp4, video/mp4v-es, text/vnd.sun.j2me.app-descriptor,
>   text/x-pcs-gcd, multipart/mixed; q=.1, multipart/vnd.sprint-pre-cache,
>   application/xhtml+xml; profile=http://www.wapforum.org/xhtml,
>   application/vnd.wap.xhtml+xml, application/sdp,
>   application/x-pcs-mcd+xml, text/plain, application/vnd.wap.wmlscriptc,
>   application/vnd.wap.wmlc application/vnd.wap.sic,
>   application/vnd.wap.slc, application/sia,
>  
application/vnd.wap.mms-message,text/x-hdml,image/mng,image/x-mng,video/mng,vide\
o/x-mng,image/bmp,text/html,image/gif
>   accept-charset = utf-8, utf-16, us-ascii, iso-8859-1, *,*
>   accept-encoding = deflate, gzip
>   accept-language = en; q=1.0, fr; q=0.5
>   content-length = 41
>   content-type = application/x-www-form-urlencoded;charset=ISO-8859-1
>   user-agent = Samsung-SPHM610 AU-OBIGO/Q04C1-1.17 MMP/2.0
>   x-network-type = EVDO
>   x-wap-profile =
>   "http://uaprof.bellmobilite.ca/BMC_Samsung_SPH-M610_AB03.rdf"
>   x-up-devcap-smartdialing = 1
>   x-up-devcap-iscolor = 1
>   x-up-devcap-screendepth = 16
>   x-up-devcap-numsoftkeys = 2
>   x-up-devcap-charset = ISO-8859-1,US-ASCII,UTF-8,UTF-16
>   x-up-devcap-screenpixels = 240,320
>   x-up-subno =
>   00005831492980x00306E274C171083168709194-023X_wap2.bellmobility.ca
>   x-up-subscriber-cos = wap2
>   Via = 1.1 e0100dawappxy02.bellmobility.ca
>   connection = close
>
> The User-Agent is clearly showing the Obigo browser.  Yet, the headers
> include the standard Openwave x-up-* additions.  I'll defer to the
> greater experience of others on the group to determine the best match.
>

People,

I was suggested an enhancement which made a lot of sense and required
little effort to implement. So I suggested to go ahead and implement it
without further ado:

     <device user_agent="Nokia 90 Developer Platform 2.0"
fall_back="nokia_generic_series80_dp20" id="nokia_generic_series90_dp20">
       <group id="product_info">
         <capability name="nokia_series" value="90"/>
         <capability name="nokia_edition" value="1"/>
       </group>

If anyone strongly objects to this, please speak up now.

Thanks

Luca

Bell Mobility using Teleca/Obigo was a guess (hence the "?"!), but data
I'm getting from HTTP headers suggest otherwise.  Is it not possible for
a handset to be using the Obigo browser while the operator uses the
Openwave gateway?  I don't think one implies the other.  Here's an
example of a Bell Mobility request from the Samsung M610 that I've
received:

   accept = text/vnd.wap.wml, text/css, text/ecmascript, image/png,
   image/gif, image/jpeg; q=0.5, image/x-bmp; q=0.3, image/vnd.wap.wbmp;
   q=0.2, audio/mid, audio/midi, audio/qcelp, audio/vnd.qcp,
   audio/vnd.qcelp, audio/aac, audio/mp3, audio/x-wav, audio/x-wave,
   audio/mpeg3, audio/mpeg, audio/mpg, audio/amr, application/x-pmd,
   application/x-cmx, application/x-pmd, audio/m4a, audio/mp4,
   audio/3gpp, audio/3gpp2, audio/mp4a-latm, video/3gpp, video/3gpp2,
   video/mp4, video/mp4v-es, text/vnd.sun.j2me.app-descriptor,
   text/x-pcs-gcd, multipart/mixed; q=.1, multipart/vnd.sprint-pre-cache,
   application/xhtml+xml; profile=http://www.wapforum.org/xhtml,
   application/vnd.wap.xhtml+xml, application/sdp,
   application/x-pcs-mcd+xml, text/plain, application/vnd.wap.wmlscriptc,
   application/vnd.wap.wmlc application/vnd.wap.sic,
   application/vnd.wap.slc, application/sia,
  
application/vnd.wap.mms-message,text/x-hdml,image/mng,image/x-mng,video/mng,vide\
o/x-mng,image/bmp,text/html,image/gif
   accept-charset = utf-8, utf-16, us-ascii, iso-8859-1, *,*
   accept-encoding = deflate, gzip
   accept-language = en; q=1.0, fr; q=0.5
   content-length = 41
   content-type = application/x-www-form-urlencoded;charset=ISO-8859-1
   user-agent = Samsung-SPHM610 AU-OBIGO/Q04C1-1.17 MMP/2.0
   x-network-type = EVDO
   x-wap-profile =
   "http://uaprof.bellmobilite.ca/BMC_Samsung_SPH-M610_AB03.rdf"
   x-up-devcap-smartdialing = 1
   x-up-devcap-iscolor = 1
   x-up-devcap-screendepth = 16
   x-up-devcap-numsoftkeys = 2
   x-up-devcap-charset = ISO-8859-1,US-ASCII,UTF-8,UTF-16
   x-up-devcap-screenpixels = 240,320
   x-up-subno =
   00005831492980x00306E274C171083168709194-023X_wap2.bellmobility.ca
   x-up-subscriber-cos = wap2
   Via = 1.1 e0100dawappxy02.bellmobility.ca
   connection = close

The User-Agent is clearly showing the Obigo browser.  Yet, the headers
include the standard Openwave x-up-* additions.  I'll defer to the
greater experience of others on the group to determine the best match.

Sincerely,
Francis

Um don't know where u got your information on bell mobility.
But all samsung browsers using them are connicting
through an openwave gateway

Same with mts, aliant, sasktel as they are all
Using bell mobility as their gateway

Kenneth gf brown




-----Original Message-----
From: wmlprogramming@yahoogroups.com [mailto:wmlprogramming@yahoogroups.com]
On Behalf Of Luca Passani
Sent: August 4, 2007 6:54 PM
To: wmlprogramming@yahoogroups.com
Subject: Re: [wmlprogramming] Re:Teleca/Obigo Browser


Thanks a lot Francis. Very useful. Do you happen to know which main versions
of the Teleca/Obigo browser can be found out there? any idea about which
hints in the HTTP request can be used to identify them?

Luca

Francis Li wrote:
> The Teleca/Obigo Browser is embedded in most (if not all) Sprint CDMA
> handsets in the US and similar operators (Bell Mobility in Canada?).
> That includes Sprint-customized versions of handsets like the Motorola
> RAZR V3m, most of the Samsung CDMA devices currently marked with a
> "generic" fallback (i.e. Samsung-SPH*), etc.  I believe recognizable
> user-agent strings include the "AU-MIC" identifier (Samsung-SPHA900
> AU-MIC-A900/2.0 MMP/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1), and
> on some handsets, an explicit Obigo string (Motorola-V3m Obigo/Q04C1
> MMP/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1).
>




As of July 14 2005, it's much easier to be banned from WMLProgramming!
Please fail to read http://groups.yahoo.com/group/wmlprogramming/ before you
post.
Yahoo! Groups Links

Thanks a lot Francis. Very useful. Do you happen to know which main
versions of the Teleca/Obigo browser can be found out there? any idea
about which hints in the HTTP request can be used to identify them?

Luca

Francis Li wrote:
> The Teleca/Obigo Browser is embedded in most (if not all) Sprint CDMA
> handsets in the US and similar operators (Bell Mobility in Canada?).
> That includes Sprint-customized versions of handsets like the Motorola
> RAZR V3m, most of the Samsung CDMA devices currently marked with a
> "generic" fallback (i.e. Samsung-SPH*), etc.  I believe recognizable
> user-agent strings include the "AU-MIC" identifier (Samsung-SPHA900
> AU-MIC-A900/2.0 MMP/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1), and on
> some handsets, an explicit Obigo string (Motorola-V3m Obigo/Q04C1
> MMP/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1).
>

The Teleca/Obigo Browser is embedded in most (if not all) Sprint CDMA
handsets in the US and similar operators (Bell Mobility in Canada?).
That includes Sprint-customized versions of handsets like the Motorola
RAZR V3m, most of the Samsung CDMA devices currently marked with a
"generic" fallback (i.e. Samsung-SPH*), etc.  I believe recognizable
user-agent strings include the "AU-MIC" identifier (Samsung-SPHA900
AU-MIC-A900/2.0 MMP/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1), and on
some handsets, an explicit Obigo string (Motorola-V3m Obigo/Q04C1
MMP/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1).

Sincerely,
Francis

How to play live video from a mobile phone on a computer?



M. Magdy Shaheen



[Non-text portions of this message have been removed]

So, first off, why would you want to deliver WML to this device? It's
got the Openwave 6.2.3 browser on it and does a pretty decent job of
handling XHTML-MP and CSS.

That said, if WML is not rendering on the device, have you tried
sending compiled bytecode (wmlc)?

Ron

--- In wmlprogramming@yahoogroups.com, "brisontheweb"
<brisontheweb@...> wrote:
>
> Any breakthroughs on how to get a WML to show up on a Chocolate or
> other Verizon Wireless 3G devices?
>
> Thanks
>

People, is there anyone here who has a clearer idea of which versions of
the Obigo/Teleca browser are out there?

I am getting crazy trying to understand how this browser maps to
different devices from different manufacturers.
Also, UA strings do not seem to provide any hint about the Obigo browser
version. Am I mistaken?

is there anyone who has contact in Teleca here?

Thanks

Luca

Randit wrote:

>I am using tomcat 5.5 as application server i want to know following
>issue
...
>2. when i use conditions in JSP page , it shows lots of empty spaces.
>is that create problem to response.

Since you use tomcat 5.5, you could just add a "trimSpace" filter. In
$CATALINA_HOME/conf/web.xml add the following <init-param> in the "jsp" servlet:

     <init-param>
         <param-name>trimSpaces</param-name>
         <param-value>true</param-value>
     </init-param>

This will remove annoying whitespaces created by dynamic parts of the JSP.

cheers,
Anders Magnus Andersen



[Non-text portions of this message have been removed]

Any breakthroughs on how to get a WML to show up on a Chocolate or
other Verizon Wireless 3G devices?

Thanks

Hello ,i am developing WAP application by using JSP and WALL tag
library. Application is working fine on LG,NOKIA and other handset,
but having problem in alcatel handset.
I have checked my response buffer and observer  that my application is
not sending all response buffer to handset
I am using tomcat 5.5 as application server i want to know following
issue
1. does my response depend on request from  different handset?
2. when i use conditions in JSP page , it shows lots of empty spaces.
is that create problem to response.
Thanks in advance.
Regards,
Pandit

New Device detected in my server:
EZZE - SL308

"UAPRof" "UserAgent":

"http://211.42.201.70/ua_profile/sl308.xml" "EZZE-SL308/BSI
AU.Browser/2.0 QO3C1 MMP/1.0"


I've found more UAProf, but I don't have any UserAgent. I am leaving
these here, in case someone may complete their info.

http://211.42.201.70/ua_profile/sl388.xml
http://211.42.201.70/ua_profile/mx200.xml
http://211.42.201.70/ua_profile/e800.xml
http://211.42.201.70/ua_profile/sl900.xml
http://211.42.201.70/ua_profile/mp500.xml
...
This directory is readable with a lot more:
http://211.42.201.70/ua_profile/


Julio Rabadáb González
http://www.somms.net

Andrea Trasatti wrote:
> The Nokia 7650 has no attempt to do XHTML, but anyway it would fit in
> level 1, of course.
believe it or not, I found out a couple of months back that the 7650
does have XHTML MP support in some embryonic form, Anyway, I would still
prefer to refer to it as a WML device....

Luca

Hi Andrea,

Thank you for taking time to reply to me.:)

We did try OMA.DD and GCD download protocol. GCD gives us a "Network
Gremlins" message on the phone while OMA is processed (since we can
see the file we try to deliver is being called, by capturing with
Wireshark)..but the phone freezes.

I'm not sure what t.wurfl.com is. And when I try to go there my bowser
times out.




--- In wmlprogramming@yahoogroups.com, Andrea Trasatti <andrea@...> wrote:
>
> Il giorno 30/lug/07, alle ore 20:04, david_musset ha scritto:
>
> > Hi folks,
> >
> > I recently purchased a SLICE phone. Actually it's for my company, and
> > we're working on delivering content like ringtones, wallpapers and
> > stuff.
> >
> > We have two other Virgin handsets: MARBL and CYCLOPS. They're very
> > similar to the SLICE. Except when we try to download ringtones.
> >
> > With Slice we can't download ringtones off Virgin Mobile wap portal,
> > VirginXL. When we tried to download from VirginXl a Java logo
> > appeared, so we guessed it uses some kind of java technology for
> > downloading stuff. The 2 other Virgin use OMA.DD which is very similar
> > to GCD.
> >
> > But the SLICE is a hard case to crack. There has to be a way to
> > download our own ringtones, but without knowing what download protocol
> > (oma, gcd, direct download…) we can't make it work.
> >
> > So my question is, do you have any experience with this Java
> > technology for downloading content (apart form games which use JAR and
> > JAD).
>
> I haven't seen this device, but my first impression is that if the
> Java VM starts it hasn't understood what you're serving.
>
> Did you capture the headers? Did you try some downloads from
> t.wurfl.com?
>
> - Andrea
>

Il giorno 22/lug/07, alle ore 12:38, Luca Passani ha scritto:

>
> Note: SonyEricsson T68i and Nokia 7650 is level -1, in spite of an
> attempt at supporting XHTML. This may apply to other devices.

The Nokia 7650 has no attempt to do XHTML, but anyway it would fit in
level 1, of course.
The first S60 device with XHTML support was the 3650 and the 7650 was
the only S60 without XHTML support of any kind.

It might be wise to try to build the clusters of devices that would
match the different levels and hopefully find edge cases and isolate
and resolve.

- Andrea

Il giorno 30/lug/07, alle ore 20:04, david_musset ha scritto:

> Hi folks,
>
> I recently purchased a SLICE phone. Actually it's for my company, and
> we're working on delivering content like ringtones, wallpapers and
> stuff.
>
> We have two other Virgin handsets: MARBL and CYCLOPS. They're very
> similar to the SLICE. Except when we try to download ringtones.
>
> With Slice we can't download ringtones off Virgin Mobile wap portal,
> VirginXL. When we tried to download from VirginXl a Java logo
> appeared, so we guessed it uses some kind of java technology for
> downloading stuff. The 2 other Virgin use OMA.DD which is very similar
> to GCD.
>
> But the SLICE is a hard case to crack. There has to be a way to
> download our own ringtones, but without knowing what download protocol
> (oma, gcd, direct download…) we can't make it work.
>
> So my question is, do you have any experience with this Java
> technology for downloading content (apart form games which use JAR and
> JAD).

I haven't seen this device, but my first impression is that if the
Java VM starts it hasn't understood what you're serving.

Did you capture the headers? Did you try some downloads from
t.wurfl.com?

- Andrea

--- In wmlprogramming@yahoogroups.com, "Bryce Nesbitt" <bryce1@...> wrote:

> Ok, then have we at least established that the OMA DTD as published is
> broken?
>

Its true, that DTD as published is broken. I came across this problem
in ready.mobi. I had to edit the local copy of this DTD on ready.mobi
so that I could validate XHTML MP 1.1 docs. As I remember, the problem
was a non-utf8 quote character towards the beginning of the document.

Ruadhan

Sean Decker wrote:
> i think this is a great idea. We are encountering a lot of inconsistency in
CSS support for devices. e.g. some devices can set the width of a field and some
cant. same with fonts etc.
yes. At the same time, though, I don't think that it makes sense to go
down to the level of capturing each and every capability for each and
every device. This would make the WURFL too hard to maintain. At the
same time, few developers would find it sustainable to multiserve apps
depending on such fine grained capabilities.
The "level" approach should strike the balance.

> The bigger challenge will be to map the devices to this capability...
>
I have a fair amount of experience with different devices. I can create
a decent start. Also, do not forget that this is an area where the
current fall_back structure is really helpful

Luca
> Luca Passani <passani@...> wrote:
> Peter, I'm starting to like this. This makes me feel like wanting to
> define new categories of XHTML support, capture that for each device as
> a WURFL capability and enable future versions of WALL to leverage that
> for optimal rendering on different cathegories of devices.
> So, off the top of my head:
>
> Passani's definition of XHTML support levels:
>
> - level "-1": no XHTML support of any kind.
> Possible WML support
> Nokia 7110, 7210 as well as
> all UP.Browser 4 and 5 devices.
>
> - level "0" : basic XHTML Support.
> Minimum screen-width: 100 pixel
> No (or very unreliable) CSS support.
> Poor table support or none at all.
> Basic forms: text field, select-option, submit button.
> May not be able to support input mask on fields.
> Ex Device: SonyEricsson T610/T616
>
> - level "1" : XHTML with some CSS support.
> Minimum sceen-width: 120 pixels.
> Hyperlinks may not be collorable by CSS.
> Basic table support: 2x2 or more.
> Colspan and rowspan may not be supported.
> "width" expressed as percentage may be unreliable.
> Ex Device: Sharp GX 10, Nokia 3650
>
> - level "2" : reserved for future use.
> Assume same capabilities as level "1"
>
> - level "3" : Excellent CSS support.
> Padding, border and margin are correctly applied.
> Can reliable apply colors to links, text and background.
> CSS graphic effects are pixel perfect
> Minimum sceen-width: 164 pixels.
> Can support complex tables (but not necessarily
> nested tables) up to 4 cells in a row.
> Not setting "font-size" produces a readable font.
> Supports background images also when applied through CSS.
> "width:100%" is correctly understood as the actual
> size of the screen.
> Ex: Openwave Mobile Browser 7, Recent MS Mobile Explorer,
> recent BlackBerrys, some (but not all) Operas. Netfront 3.3,
> Safari, PSP.
>
> - level "4" : Level 3 + Ajax support.
> Toggle display property. XMLHTTPRequest(). InnerHTML()
>
> The reason why I left level "2" empty is that I feel there are quite a
> number of devices between 1 and 3, but I wasn't sure how to discriminate
> between the two groups or even if such discrimination made sense (most
> people will want to provide a single simple view for everything legacy,
> and focus on reliable XHTML support for high end devices). I think that
> Nokia 5300, which I struggled a lot with over the past few months, would
> be a great example of level "2" device. It won't fit into 3, but it
> would almost seem unfait to degrade it to "1".
>
> Observe how I did not mention the "float" CSS property. The reason for
> this is that it would have taken a bunch of Nokia devices out of level "3"
>
> Note: SonyEricsson T68i and Nokia 7650 is level -1, in spite of an
> attempt at supporting XHTML. This may apply to other devices.
>
> Finally, an important note: apart from the minimal width requirement,
> screen size is an independent variable in all of these.
>
> Any comments?
>
> Luca
>
> ph3n0m666 wrote:
>
>> Luca
>>
>> No problem, this is part of a css file used that was accessed by an
>> Nokia N75 and a Sony Ericsson K800i
>>
>> css code:
>> div.main {
>> display:block;
>> padding:4px 0px 3px 15px;
>> color:#000;
>> background: url('../images/arrow_small.gif') 0px 50% #eef5ff no-repeat;
>> border-top:1px solid #dee3ff;
>> color:#000;
>> margin:0;
>> width:100%;
>>
>> }
>>
>> Basically putting an image background, with some padding, etc on a div
>>
>> output xhtml
>> <div class="footer"><a href="index">index</a></div>
>>
>> Now the N75 shows the link perfectly - the background to the div is a
>> small arrow, aligned to the left, and the text "index", 15 pixels to
>> the right of it. Something like this
>>
>> -> Index
>>
>> However the SE K800i, overlays the text ontop of the image, therefore
>> ignoring the padding of 15 pixels
>>
>> This is just one example of the differences, I have found from device
>> to device that both are have their prefered markup set to "xhtml"
>>
>
>
>
>
>
>
> ---------------------------------
> Need a vacation? Get great deals to amazing places on Yahoo! Travel.
>
> [Non-text portions of this message have been removed]
>
>
>
> As of July 14 2005, it's much easier to be banned from WMLProgramming!
> Please fail to read http://groups.yahoo.com/group/wmlprogramming/ before you
post.
> Yahoo! Groups Links
>
>
>
>
>
>

i think this is a great idea. We are encountering a lot of inconsistency in CSS
support for devices. e.g. some devices can set the width of a field and some
cant. same with fonts etc. The bigger challenge will be to map the devices to
this capability...

Luca Passani <passani@...> wrote:
Peter, I'm starting to like this. This makes me feel like wanting to
define new categories of XHTML support, capture that for each device as
a WURFL capability and enable future versions of WALL to leverage that
for optimal rendering on different cathegories of devices.
So, off the top of my head:

Passani's definition of XHTML support levels:

- level "-1": no XHTML support of any kind.
Possible WML support
Nokia 7110, 7210 as well as
all UP.Browser 4 and 5 devices.

- level "0" : basic XHTML Support.
Minimum screen-width: 100 pixel
No (or very unreliable) CSS support.
Poor table support or none at all.
Basic forms: text field, select-option, submit button.
May not be able to support input mask on fields.
Ex Device: SonyEricsson T610/T616

- level "1" : XHTML with some CSS support.
Minimum sceen-width: 120 pixels.
Hyperlinks may not be collorable by CSS.
Basic table support: 2x2 or more.
Colspan and rowspan may not be supported.
"width" expressed as percentage may be unreliable.
Ex Device: Sharp GX 10, Nokia 3650

- level "2" : reserved for future use.
Assume same capabilities as level "1"

- level "3" : Excellent CSS support.
Padding, border and margin are correctly applied.
Can reliable apply colors to links, text and background.
CSS graphic effects are pixel perfect
Minimum sceen-width: 164 pixels.
Can support complex tables (but not necessarily
nested tables) up to 4 cells in a row.
Not setting "font-size" produces a readable font.
Supports background images also when applied through CSS.
"width:100%" is correctly understood as the actual
size of the screen.
Ex: Openwave Mobile Browser 7, Recent MS Mobile Explorer,
recent BlackBerrys, some (but not all) Operas. Netfront 3.3,
Safari, PSP.

- level "4" : Level 3 + Ajax support.
Toggle display property. XMLHTTPRequest(). InnerHTML()

The reason why I left level "2" empty is that I feel there are quite a
number of devices between 1 and 3, but I wasn't sure how to discriminate
between the two groups or even if such discrimination made sense (most
people will want to provide a single simple view for everything legacy,
and focus on reliable XHTML support for high end devices). I think that
Nokia 5300, which I struggled a lot with over the past few months, would
be a great example of level "2" device. It won't fit into 3, but it
would almost seem unfait to degrade it to "1".

Observe how I did not mention the "float" CSS property. The reason for
this is that it would have taken a bunch of Nokia devices out of level "3"

Note: SonyEricsson T68i and Nokia 7650 is level -1, in spite of an
attempt at supporting XHTML. This may apply to other devices.

Finally, an important note: apart from the minimal width requirement,
screen size is an independent variable in all of these.

Any comments?

Luca

ph3n0m666 wrote:
> Luca
>
> No problem, this is part of a css file used that was accessed by an
> Nokia N75 and a Sony Ericsson K800i
>
> css code:
> div.main {
> display:block;
> padding:4px 0px 3px 15px;
> color:#000;
> background: url('../images/arrow_small.gif') 0px 50% #eef5ff no-repeat;
> border-top:1px solid #dee3ff;
> color:#000;
> margin:0;
> width:100%;
>
> }
>
> Basically putting an image background, with some padding, etc on a div
>
> output xhtml
> <div class="footer"><a href="index">index</a></div>
>
> Now the N75 shows the link perfectly - the background to the div is a
> small arrow, aligned to the left, and the text "index", 15 pixels to
> the right of it. Something like this
>
> -> Index
>
> However the SE K800i, overlays the text ontop of the image, therefore
> ignoring the padding of 15 pixels
>
> This is just one example of the differences, I have found from device
> to device that both are have their prefered markup set to "xhtml"






---------------------------------
Need a vacation? Get great deals to amazing places on Yahoo! Travel.

[Non-text portions of this message have been removed]

I checked in a WURFL update into CVS yesterday. Also contains some
interesting new devices.

Still missing a bunch of Kyocera I got from Steve Kamerman, but still
worth giving it a spin for people in GSM

Luca

Hi
Ok i will provide such patch file.

Regards
Max

PS Vsegda pogaluysta :)

Luca Passani пишет:
>
>
> Max, I think I understand what you mean, but I am not 100% sure.
>
> Assuming I do...
>
> Do you understand how a patch file work? if you do, what about coding
> your information in the form of a patch file? this would have multiple
> advantages:
> - you can update the video info independently of the big WURFL
> - you canmore easily share the information
>
> Spasibo
>
> Luca
>

--- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:
> >  Or defend the publication of an invalid DTD?
> >
> I never did that. OMA sucks. And so does W3C. This community is about
> getting developers together and let them help each other to get the job
> done.

Ok, then have we at least established that the OMA DTD as published is
broken?

Dear group

Is there version of JMF for mobiles ?







[Non-text portions of this message have been removed]