Loading ...
Sorry, an error occurred while loading the content.

Re: [wmlprogramming] new capabilities in Wurfl

Expand Messages
  • Boris Granveaud
    the problem is that you are considering adaptation to a terminal at a high-level. You say this device doesn t support access keys, so I send back WML 1.1 . I
    Message 1 of 7 , Oct 3, 2002
    View Source
    • 0 Attachment
      the problem is that you are considering adaptation to a terminal at a
      high-level. You say "this device doesn't support access keys, so I send
      back WML 1.1". I think the whole interest of Wurfl is to be very fine
      grained. With Wurfl, you can say "this terminal supports WML 1.3 except
      the access keys and it ignores <pre> tags". However, it requires more
      efforts and flexibility in the adaptation process.

      Concerning the version of WML included in the response, I'm not sure.
      There is no difference in the returned mime type, so the only place
      there could be a difference is in the xml public-id and system-id, is
      that right? I'm not sure that the WML browser verify that. It would be
      interesting to know this.

      >Hello,
      >
      >My remarks to this arguement from a previous mail are included at the bottom
      >
      >On Thursday 03 October 2002 07:58 pm, luca passani wrote:
      >
      >
      >>Zev Blut wrote:
      >>
      >>
      >>>>For example, the 'accesskey' attribute doesn't exist in 1.1 and we
      >>>>already have a capability 'accesskey_support'. So, it seems to be
      >>>>redundant with 'wml12' or 'wml13'.
      >>>>
      >>>>
      >>>Ahh, but you assume all handsets work properly with this.
      >>>For example the Trium Eclipse is wml1.3 capable and accepts the accesskey
      >>>attribute, but the phone will not actually work with it. Thus I can
      >>>display a page that has accesskey attributes in it, but when I click a
      >>>number on the phone's number pad it will not jump to the designated link.
      >>>
      >>>
      >>Zev, maybe I am missing saomething, but the example you
      >>make does not contradict my and Boris' point, it actually reaffirms it.
      >>
      >>You don't care about the alleged mark-up version. You care
      >>about the phone capability. You want to tell your application
      >>to use accesskeys if and only iff the phone supports it.
      >>WURFL lets you do that very easyly with the support_accesskey capability
      >>
      >>luca
      >>
      >>
      >
      >=Previous Mail
      >Subject: Re: [wmlprogramming] WURFL additions based on image handling and WML
      > version"
      >Date: Tue, 3 Sep 2002 18:32:57 +0900
      >=
      >
      >Hello,
      >
      >My comments regarding adding a "markup" group are below.
      >
      >On Tuesday 03 September 2002 01:59 am, Luca Passani wrote:
      >
      >
      >> > Outside of images here are a few other suggestions.
      >> > Can we add a group to track what versions of WML the handset supports?
      >> > Something such as the following below?
      >> >
      >> > <group id="markup">
      >> > <capability name="wml1.1" value="true"/>
      >> > <capability name="wml1.2" value="false"/>
      >> > <capability name="wml1.3" value="false"/>
      >> > <capability name="preferred_markup" value="wml1.1"/>
      >> > </group>
      >> >
      >> > Sometimes handsets and even worse gateways are picky about what they
      >> > support.
      >>
      >> mmmm, yes and know. I am not sure this is the way most developers
      >> look at a phone, so I would tend not to put it in the standard WURFL,
      >> unless someone has good arguments against that...
      >>
      >>
      >>
      >
      >In many cases the handset sends what versions of WML it supports in the HTTP
      >ACCEPT header, but not always. In those cases it would be nice if the WURFL
      >contained the information. Let me explain why I look at a phone and want to
      >know the WML version it supports.
      >
      >I can foresee a few reasons why you would want to know what versions of WML a
      >handset supports. We can agree that when generating WML we must include a
      >declaration stating what version of WML the following markup is in. If the
      >handset does not send what version of WML it accepts, I will have to find
      >some other way of determining what is the proper version of WML to output.
      >This is important at the very least, because some handsets do not like being
      >sent WML that is a version greater than it supports (irrelevant to whether or
      >not I am using tags and attributes from the newer version).
      >
      >Now I want to use the current WURFL to determine if the incoming handset
      >supports the use of access keys in anchors, if it does then I can use either
      >WML 1.3 or WML 1.2 and if does not well we would make the assumption that it
      >is WML 1.1. The Mitsubishi Trium Eclipse does support WML 1.2, but the
      >handset chooses to ignore all access key presses, so in the WURFL it would be
      >set to not support access keys. I have now excluded the Trium Eclipse from
      >the other additions to WML 1.2 like the use of <pre> tags. How can I know
      >what version of WML to output without having to do overly complicated
      >analysis of what features the handset supports?
      >
      >The addition of the "preferred_markup" is something that most likely suits
      >only me, as I use it as a quick way to get the best markup for the phone.
      >But I do think knowing what versions of WML a handset supports is a necessary
      >addition.
      >
      >
      >Maybe I am making things more difficult than it needs to be. If someone can
      >explain why I should not care about outputting the proper WML version in my
      >WML markup, please enlighten me. Of course, remarks such as use product x
      >that will do this automagically for you is not enlightenment :-)
      >
      >Best,
      >Zev Blut
      >
      >Please read the FAQ before you ask questions: http://www.thewirelessfaq.com
      >
      >Visit http://groups.yahoo.com/group/wmlprogramming for archive and subscription options
      >
      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
      >
      >


      --
      Boris Granveaud
      Head of R&D
      Ubicco, a Fi SYSTEM company
      Tél: +33(0)155040303 Fax: +33(0)155040302

      Develop your European mobiles services for i-mode or WAP
      with Take it MoVIE http://www.ubicco.com/takeitmovie.htm
    • Zev Blut
      Hello, ... First I do not send back WML 1.1 just because the device does not support access keys. I simply do not use accesskeys attributes for that device.
      Message 2 of 7 , Oct 3, 2002
      View Source
      • 0 Attachment
        Hello,

        On Thursday 03 October 2002 09:20 pm, you wrote:
        > the problem is that you are considering adaptation to a terminal at a
        > high-level. You say "this device doesn't support access keys, so I send
        > back WML 1.1". I think the whole interest of Wurfl is to be very fine
        > grained. With Wurfl, you can say "this terminal supports WML 1.3 except
        > the access keys and it ignores <pre> tags". However, it requires more
        > efforts and flexibility in the adaptation process.
        >

        First I do not send back WML 1.1 just because the device does not support
        access keys. I simply do not use accesskeys attributes for that device.
        Fine grained control is great, the problem is in when do you decide what to
        output? Do you do it after you have made all of your checks on what the
        handset can do? For my purposes, that would be ghastly. I would like to
        know quite soon after a request comes in what markup and versions the handset
        supports. Then I can do more fine grained checking.

        > Concerning the version of WML included in the response, I'm not sure.
        > There is no difference in the returned mime type, so the only place
        > there could be a difference is in the xml public-id and system-id, is
        > that right? I'm not sure that the WML browser verify that. It would be
        > interesting to know this.
        >

        Yes it is in the DOCTYPE declaration of the xml.
        Handsets vary on how they interpret this, but some require you to have the
        proper declaration. Some Gateways do too.

        Best,
        Zev

        > >Hello,
        > >
        > >My remarks to this arguement from a previous mail are included at the
        > > bottom
        > >
        > >On Thursday 03 October 2002 07:58 pm, luca passani wrote:
        > >>Zev Blut wrote:
        > >>>>For example, the 'accesskey' attribute doesn't exist in 1.1 and we
        > >>>>already have a capability 'accesskey_support'. So, it seems to be
        > >>>>redundant with 'wml12' or 'wml13'.
        > >>>
        > >>>Ahh, but you assume all handsets work properly with this.
        > >>>For example the Trium Eclipse is wml1.3 capable and accepts the
        > >>> accesskey attribute, but the phone will not actually work with it.
        > >>> Thus I can display a page that has accesskey attributes in it, but when
        > >>> I click a number on the phone's number pad it will not jump to the
        > >>> designated link.
        > >>
        > >>Zev, maybe I am missing saomething, but the example you
        > >>make does not contradict my and Boris' point, it actually reaffirms it.
        > >>
        > >>You don't care about the alleged mark-up version. You care
        > >>about the phone capability. You want to tell your application
        > >>to use accesskeys if and only iff the phone supports it.
        > >>WURFL lets you do that very easyly with the support_accesskey capability
        > >>
        > >>luca
        > >
        > >=Previous Mail
        > >Subject: Re: [wmlprogramming] WURFL additions based on image handling and
        > > WML version"
        > >Date: Tue, 3 Sep 2002 18:32:57 +0900
        > >=
        > >
        > >Hello,
        > >
        > >My comments regarding adding a "markup" group are below.
        > >
        > >On Tuesday 03 September 2002 01:59 am, Luca Passani wrote:
        > >> > Outside of images here are a few other suggestions.
        > >> > Can we add a group to track what versions of WML the handset supports?
        > >> > Something such as the following below?
        > >> >
        > >> > <group id="markup">
        > >> > <capability name="wml1.1" value="true"/>
        > >> > <capability name="wml1.2" value="false"/>
        > >> > <capability name="wml1.3" value="false"/>
        > >> > <capability name="preferred_markup" value="wml1.1"/>
        > >> > </group>
        > >> >
        > >> > Sometimes handsets and even worse gateways are picky about what they
        > >> > support.
        > >>
        > >> mmmm, yes and know. I am not sure this is the way most developers
        > >> look at a phone, so I would tend not to put it in the standard WURFL,
        > >> unless someone has good arguments against that...
        > >
        > >In many cases the handset sends what versions of WML it supports in the
        > > HTTP ACCEPT header, but not always. In those cases it would be nice if
        > > the WURFL contained the information. Let me explain why I look at a
        > > phone and want to know the WML version it supports.
        > >
        > >I can foresee a few reasons why you would want to know what versions of
        > > WML a handset supports. We can agree that when generating WML we must
        > > include a declaration stating what version of WML the following markup is
        > > in. If the handset does not send what version of WML it accepts, I will
        > > have to find some other way of determining what is the proper version of
        > > WML to output. This is important at the very least, because some handsets
        > > do not like being sent WML that is a version greater than it supports
        > > (irrelevant to whether or not I am using tags and attributes from the
        > > newer version).
        > >
        > >Now I want to use the current WURFL to determine if the incoming handset
        > >supports the use of access keys in anchors, if it does then I can use
        > > either WML 1.3 or WML 1.2 and if does not well we would make the
        > > assumption that it is WML 1.1. The Mitsubishi Trium Eclipse does support
        > > WML 1.2, but the handset chooses to ignore all access key presses, so in
        > > the WURFL it would be set to not support access keys. I have now
        > > excluded the Trium Eclipse from the other additions to WML 1.2 like the
        > > use of <pre> tags. How can I know what version of WML to output without
        > > having to do overly complicated analysis of what features the handset
        > > supports?
        > >
        > >The addition of the "preferred_markup" is something that most likely suits
        > >only me, as I use it as a quick way to get the best markup for the phone.
        > >But I do think knowing what versions of WML a handset supports is a
        > > necessary addition.
        > >
        > >
        > >Maybe I am making things more difficult than it needs to be. If someone
        > > can explain why I should not care about outputting the proper WML version
        > > in my WML markup, please enlighten me. Of course, remarks such as use
        > > product x that will do this automagically for you is not enlightenment
        > > :-)
        > >
        > >Best,
        > >Zev Blut
        > >
        > >Please read the FAQ before you ask questions:
        > > http://www.thewirelessfaq.com
        > >
        > >Visit http://groups.yahoo.com/group/wmlprogramming for archive and
        > > subscription options
        > >
        > >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.