W3C home > Mailing lists > Public > public-bpwg@w3.org > October 2008

[minutes] BPWG F2F day 2 - 2008-10-21

From: Francois Daoust <fd@w3.org>
Date: Wed, 22 Oct 2008 12:37:15 +0200
Message-ID: <48FF025B.2040008@w3.org>
To: MWI BPWG Public <public-bpwg@w3.org>

Hi again :-)

The minutes of day 2 of our F2F are available at:
  http://www.w3.org/2008/10/20-bpwg-minutes.html

A day well spent on mobileOK Basic Tests, mobileOK Scheme, the Korean 
Task Force report, the addendum to Mobile Web Best Practices, Mobile Web 
Application Best Practices, the Accessibility documents, and a bit of 
POWDER, Device Description Repository, and Mobile Web for Social 
Development.

Francois.


21 Oct 2008

    [2]Agenda

       [2] 
http://www.w3.org/2005/MWI/BPWG/Group/Meetings/Mandelieu/agenda.html

    See also: [3]IRC log - [4]Day 1 minutes

       [3] http://www.w3.org/2008/10/21-bpwg-irc
       [4] http://www.w3.org/2008/10/20-bpwg-minutes

Attendees

    Present
           Abel, Nacho, Adam, Rob, Jeff, Jonathan, Francois, KaiS, Dom,
           DKA, Seungyun, SeanP, PhilArcher, Philipp

    Observers
           Shadi_Abou-Zahra (W3C), Kangchan_Lee (ETRI), Kai_Hendry
           (Aplix), Andrew_Arch (W3C), Shawn_Henry (W3C),
           Sophie_Aveline, Hyunjeong_Lee (ETRI), Stephane_Boyera (W3C),
           Rotan Hanrahan (MobileAware)

    Regrets
           Soonho, Bryan

    Chair
           Jo, DKA

    Scribe
           Francois, SeanP, Dan, Kai_Hendry, Rob, Nacho, Dom

Contents

      * [5]Topics
          1. [6]mobileOK Basic Tests 1.0
          2. [7]mobileOK Scheme
          3. [8]Korean Task Force report
          4. [9]Mobile Web for Social Development (MW4D) Presentation
          5. [10]Addendum to the Mobile Web Best Practices (BP1.5)
          6. [11]Mobile Web Application/s Best Practices (BP2)
          7. [12]BP2 - One Web section
          8. [13]BP2 - Conservative use of resources
          9. [14]BP2 - 3.8.3 Use Device Classification to Simplify
             Content Selection/Adaptation
         10. [15]BP2 - 3.8.5 Provide for Both Graceful Degradation &
             Progressive Enhancement of CSS
         11. [16]Device Description Repository (DDR) Simple API
             interlude
         12. [17]Liaison with ETSI - Statement from Bruno
         13. [18]BP2 - 3.8.4 Provide Alternatives to Client-Side
             Scripting
         14. [19]BP2 - 3.8.2 Use Reliable Methods for Determining Script
             Support
         15. [20]BP2 - 3.7 User Interface
         16. [21]BP2 - 3.7.5 Use hash URLs to Preserve Browser History
             and Enable Deep Links
         17. [22]BP2 - 3.7.6 Use URI Schemes for Device Functions
         18. [23]BP2 - Latency
         19. [24]BP2 - JSON vs. XML - the final conflict
         20. [25]Pre-discussion on Accessibility documents
         21. [26]POWDER for mobileOK
         22. [27]Accessibility Documents
         23. [28]Next F2F meeting
      * [29]Summary of Action Items
      _________________________________________________________

    DKA: [welcomes participants]

    <jeffs> welcomes in progress at TPAC face-to-face

    DKA: Spent yesterday on Content Transformation
    ... Made a lot of progress, which is good, but we now only have one
    day to run 1.5 days of schedule.
    ... I'd like to clean our morning session so that we can address
    Mobile Web Applications Best Practices

    Jo: We could rather do a few easy things such as mobileOK Scheme,
    mobileOK Basic Tests, then we have Stéphane
    ... in short try to leave the afternoon for Mobile Web Applications
    Best Practices.

    DKA: [playing with the agenda]

    <DKA> [30]http://docs.google.com/Doc?docid=dd3jk8v_128gb3xp5hq&hl=en

      [30] http://docs.google.com/Doc?docid=dd3jk8v_128gb3xp5hq&hl=en

mobileOK Basic Tests 1.0

    <jo>
    [31]http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/0050.htm
    l

      [31] http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/0050.html

    <dom> [32]mobileOK draft 45

      [32] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/081018

    <jo> [33]mobileOK Basic 1.0 Tests

      [33] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Basic-1.0-Tests/081018

    Jo: I'd like to start with a first resolution on mobileOK Basic
    Tests. I sent an email shortly before the meeting.
    ... Changes in the latest draft are pretty limited.

    Jo: the only difference is the insertion of the HTTPS section,
    removed from the HTTP Response section because it did not quite fit
    there. This was triggered by a comment from the Web Security Context
    Working Group.

    <Zakim> francois, you wanted to note that Thomas said "close enough"

    Jo: I'd like us to resolve that we request transition of this
    document to Proposed Recommendation.

    francois: I sent the link to Thomas yesterday who said "close
    enough".

    <dom> PROPOSED RESOLUTION: Request Advancement of mobileOK Basic
    Tests to PR, skipping CR on the basis that implementation experience
    informed the return to Last Call, and those issues have been dealt
    with.

    <nacho> +1

    <DKA> +1

    <jeffs> +1

    <rob> +1

    <abel> +1

    <DKA> +1 for jo (in absentia)

    <SeanP> +1

    <dom> +1

    <dom> PROPOSED RESOLUTION: Request Advancement of mobileOK Basic
    Tests to PR, not waiting until the checker catches up with latest
    small change, skipping CR on the basis that implementation
    experience informed the return to Last Call, and those issues have
    been dealt with.

    dom: independently of the update of the Checker?

    Jo: I'd prefer so. What do you advise?

    dom: yup.

    RESOLUTION: Request Advancement of mobileOK Basic Tests to PR, not
    waiting until the checker catches up with latest small change,
    skipping CR on the basis that implementation experience informed the
    return to Last Call, and those issues have been dealt with.

    <jeffs> +1

    DKA: wonderful outcome, and the resolution is taken before 9:30am
    :-)

mobileOK Scheme

    Jo: OK, back to mobileOK Scheme.

    <jo> [34]mobileOK Scheme

      [34] http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/0049.html

    Jo: A bit of history, two years ago, one mobileOK, splitted into
    mobileOK Basic and Pro, yada yada. I ended up being the editor of
    the Scheme document.
    ... The document explains what are the relations between the best
    practices and mobileOK, how to claim for mobileOK confromance.
    ... It is a relatively short document

    [scrolling through the document]

    Jo: The "claiming conformance" part will have to be revised on the
    light of the legal license we talked about yesterday.
    ... The section details how put a machine-readable claim in a page.
    ... The RDFa solution is a bit misleading since an RDFa doc is by
    definition not mobileOK.
    ... but it could be put in a representation that is not the mobileOK
    representation. Anyway.
    ... In short, I think the document is the one we should produce but
    the details need to be sorted out.
    ... If you have other views, please say so.

    DKA: do you need a machine-readable claim to claim conformance? Does
    the presence of the image constitute a claim in itself?

    Jo: That's one thing we need to resolve.
    ... We may consider that putting the logo is enough.

    Kai: If we have a machine-readable claim, it makes propagation
    mobileOK easier.

    DKA: Taking it from the perspective of a site manager of company X.
    ... They know that their resources are mobileOK, and now they want
    to set the claim.
    ... What's the workflow?

    <Zakim> Kai, you wanted to point out that maschine readable claim
    may aid in propagating mobileok

    Jo: I think it's important not to trivialize the notion of a claim.
    ... It's an assertion made by someone that something is true at a
    given point in time. A logo doesn't say "Jo said that resource X is
    mobileOK on 20 Oct 2008".
    ... The notion of trust is important
    ... POWDER contains more information, so that could be the reason to
    push this forward.

    jeffs: could we mandate some string in the ALT attribute that goes
    with the logo?

    Jo: I don't really want us to go down that path.

    DKA: The barrier to adoption is higher with POWDER, because people
    will then have both to understand mobileOK AND POWDER. That may not
    be as easy as it seems.

    Kai: POWDER would help for groups of resources as well. You can
    group resources in one POWDER file.

    DKA: I don't think that's POWDER against logo. It's more how to do
    it for Mom's and Pop's web sites. And then POWDER could be used for
    Pro sites.
    ... What can we resolve today about this?

    <hendry> how about the validator maintains a registry of MobileOK
    conforming sites?

    Jo: I appreciate the point on simplicity, but I think we should
    emphasize the fact that POWDER contains more information.

    <Zakim> Kai, you wanted to point out that there is a section in the
    licence which says that groups of resources can be claimed to be
    mobileok. this may need maschine readability as well.

    DKA: So the workflow would be: you check a page, and you get the
    POWDER file that you could put at the root of your server. Maybe
    that should be part of the Checker's results then.

    Kai: if we want people to adopt mobileOK, it has to be true.

    jeffs: I push my students to run their pages through the validator,
    and what they get as a result is a short piece of text that they can
    put in their page. Easy. And the thing is it puts the brand out
    there.

    Andrew: adding the date the logo could help improve the information
    carried out by the logo

    Hendry: maybe we could maintain a registry of mobileOK web sites.
    ... I don't see it really working otherwise. The assertion won't be
    always true.

    Jo: I acknowledge that Kai has a point.
    ... In response to Jeffs, the point in mobileOK is that there are
    little details we want to push forward. It's a statement that at
    some future point when you resolve a URI, it will be
    mobile-friendly.
    ... Running a checker is not necessary (although most probable).
    ... In particular, it's not so much a claim saying "I passed the
    tests" even though it is by definition.

    <DKA> PROPOSED RESOLUTION: With regard to MobileOK Scheme, it must
    be rationalized with the new terms & conditions of the logo usage.
    Some machine-reable version of the claim must be present - the logo
    is not enough on its own.

    dom: I think POWDER is a nice thing to encourage, but having the
    logo is the most important thing to have for people in the short
    term.
    ... Personally, I would certain go to say that the logo is enough.

    <DKA> PROPOSED RESOLUTION: With regard to MobileOK Scheme, it must
    be rationalized with the new terms & conditions of the logo usage.
    The logo is enough to claim conformance. However, we will encourage
    checkers to provide end users with not only the logo but also
    instructions for claiming with POWDER to encourage the spread of
    POWDER-based claims.

    <dom> (is mobileOK scheme targeted to be a WG Note?)

    <dom> [the latest draft of mobileOK scheme says "This document was
    developed by the Mobile Web Best Practices Working Group. The
    Working Group expects to advance this Working Draft to
    Recommendation"]

    <jeffs> (reluctantly) agree with Kai about including date

    DKA: having the checkers return both the logo and the POWDER file
    would help go in the direction we want people to go in the end.

    <Zakim> Kai, you wanted to propose to add the date

    Kai: My main concern is really about the value of the logo. I would
    be happy to use the logo. I would just suggest that we take the idea
    to add the date.

    <DKA> PROPOSED RESOLUTION: With regard to MobileOK Scheme, it must
    be rationalized with the new terms & conditions of the logo usage
    (including putting the date in the meta-data of the logo). The logo
    is enough to claim conformance. However, we will encourage checkers
    to provide end users with not only the logo but also instructions
    for claiming with POWDER to encourage the spread of POWDER-based
    claims.

    <Zakim> jo, you wanted to respond to Dom

    Jo: what we have produced here is an image without substance.

    Kai: I agree. But that's not without substance.

    <Kai> There is a licence connected to it, which gives it more weight

    dom: I agree. The question is: are we going to go around and chase
    people that use POWDER or the logo incorrectly?

    <Zakim> hendry, you wanted to say how about at least watering down
    "claim conformance" to "checked with" (less substance)

    dom: This would really depends on whether people really use
    mobileOK, but it's independent of the fact that the claim is made
    using a machine-readable claim or not.

    Hendry: I was suggesting that we tone down "claim" to "checked
    with".

    Jo: I think it makes it as valuable as the sticker my kids get at
    the dentist: "I brushed my teeth this morning".

    <rob> +1

    <jeffs> +1 on resolution

    <dom> +1

    <nacho> +1

    DKA: I think the proposed resolution here allows for the most basic
    needs and the evolution towards a more complex scenario.

    <jo> 0

    <abel> +1

    <hendry> -1

    <SeanP> +1

    <Kai> 0

    <DKA> +1

    Kai: Just to say that since you can provide the claim in a POWDER
    form along with the text for the logo, we may want to consider that
    to make POWDER mandatory.

    RESOLUTION: With regard to MobileOK Scheme, it must be rationalized
    with the new terms & conditions of the logo usage (including putting
    the date in the meta-data of the logo). The logo is enough to claim
    conformance. However, we will encourage checkers to provide end
    users with not only the logo but also instructions for claiming with
    POWDER to encourage the spread of POWDER-based claims.

    <DKA> �1

    <Zakim> Jo, you wanted to respond to Dom's question on future status
    of document

    dom: will this be going to be a note or a Rec?

    Jo: A note in my view.

    [break]

Korean Task Force report

    <seungyun> see
    [35]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Korean/

      [35] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Korean/

    <francois> Seungyun: I will explain the status of the Korean TF
    created last March.

    <JonathanJ>
    [36]http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Korean/#documen
    ts

      [36] 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Korean/#documents

    seungyun: want to avoid fragmentation of standards
    ... wanted to create a trial service report
    ... gap analyis, requirements for new standards
    ... showing roadmap
    ... want to issue issue a report in January 2009
    ... two documents - status of trial and 1st draft of gap analysis
    ... goal of the trial service is to defin the feasibility of the web
    standard
    ... have many member to invoke the trial service
    ... will do a three year project
    ... 2nd phase is an activation stage for apps and contents
    ... 3rd phase is to complete the mobileok eco system
    ... there are 14 organisations participating
    ... this year we are developing some key components such a DDR, Test
    and Certifiaction server...
    ... web browser, web portal

    seungyun: using device inonformantion
    ... showing service scenario
    ... issues regarding device context key
    ... real world deployment issues
    ... no key context of device
    ... in Korea URI based devilery
    ... Korean operators do it their way, instead of using standards
    ... interested in providing mobileOK services
    ... want to provide clearer path for operators to conform to
    standards
    ... no trustmark for mobileOK conformance
    ... Koreans considering using their own logo/trustmark for mobileOK

    <JonathanJ>
    [37]http://docs.google.com/View?docid=ddkw3489_43cfkqjsdm

      [37] http://docs.google.com/View?docid=ddkw3489_43cfkqjsdm

    seungyun: content adaption different meaning to CT
    ... content adaption includes media transformation
    ... types of mobile device ISSUE. legacy devices not being supported
    ... video media is very important in Korea, mobile IPTV is popular.
    ISSUE re supporting this in mobile
    ... trial in development. In december there will be further results
    published.

    <dom> [38]mobileOK logo

      [38] http://www.w3.org/2005/11/MWI-Icons/mobileOK.png

    jo: restate issue re logo/trustmark

    <Kai> DKA: will rigo's information yesterday address this issue?

    seungyun: cannot use logo because our rules are different
    ... we need to resolve fragmentation issues between Korea & W3C

    jo: asks what is the requirement for different devices (asking for
    clarification)

    seungyun: contents providers use UA strings to provide services
    ... trying to employ standard UA prof approach

    jeffs: wondering about different media types like flash & mobileOK

    seungyun: look&feel is very important for mobileOK adoption using
    visual media

    Kai: suggests using DDC and asks about minimum requirements

    seungyun: addressing DDC problem. considering profile based DDC.
    ... size issues different in Korea

    <Kai> seungyun: we are setting the page size limit at 50 K rather
    than 20K

    hendry: issues surround trustmark, validity, suggests upto date
    realtime checking of mobileOK conformance

    seungyun: discussing certificate with Figure 3: Basic service
    scenario for mobileOK trial service

    jo: comments the koreans have taken mobileOK to a greater level of
    sophistication than we have

    <Kai> JonathanJ: showing the gap analysis document

    JonathanJ: going through figure 1
    ... analyis of gaps, three of them
    ... three types of gaps explained in figure
    ... and relations to activities in W3C

    <Kai> jonathanJ: gap 1 - perception differences, gap 2 .- activity
    differences, gap 3 - diffs in standards

    JonathanJ: three main inputs; mobileOK forum, forum's member
    requirements & industry at large
    ... gap1 market requirements, gap2: standardization scope; gap3:
    standards
    ... focused on gap2 & gap3
    ... figure 3 activies in the W3C
    ... table 1: comparison chart of differences between elements of
    mobileOK in Korea and W3C
    ... mobileOK basic tests 1.0 <---> K-mobileOK basic tests 1.0

    jo: asks for clarification re character sets

    JonathanJ: supporting both EUC-KR & UTF-8

    seungyun: UTF-8 has the emphasis, though we test *both*

    JonathanJ: DDC <---> K-DDC 1.5
    ... trustmark issue again raised
    ... increate value to 50 for external resources
    ... page size increase to 50K
    ... we need to implement DDC
    ... new document K-MWBP 1.5 addressing 20 items

    <dom> doesn't the web compatibility test do this?
    [39]http://www.w3.org/2008/06/mobile-test/

      [39] http://www.w3.org/2008/06/mobile-test/

    JonathanJ: type2 relasonship with full browsing. in Korea many way
    for "full browsing" to be achieved
    ... organising deployment task force
    ... interested in addressing mobile widgets

    DKA: asks to follow widget standards

    jonathanJ: yes, will follow standards
    ... K-G3-002 evolution of DDC --> K-DDC 1.5
    ... html4 included along with xhtml
    ... higher minumum screen sizes

    jo: how can screen size be tested?

    jonathanJ: tests not considered
    ... PNG is added
    ... supporting ECMAscript 3
    ... & AJAX
    ... & SSL
    ... & DOM L1/2/3 & events
    ... Mobile Web Best Practises translated ( no modifications )
    ... CT Guidelines not started
    ... looking at 2.0 applications
    ... [APPENDIX2: Comparison Table: MWBP 1.0 and K-MWBP 1.5]
    ... Black icon is defined
    ... finalised at end of year (gap analysis)
    ... & proposal coming too

    seungyun: overal picture is we support more

    DKA: can we take some elements and import it?

    jo: we want to use your work
    ... there are practical issues, what can we help you with & how can
    we work together?

    jonathanJ: possibility of back translating additions

    seungyun: wanting to avoid fragmentation by working together

    jo: suggests liasing telcons
    ... in a month's time?

    seungyun: every two weeks from there?

    jonathanJ: not happy, but ok with this

    <jo> ACTION: Dan to liaise with Seungyun and Jonathan re setting up
    a call in 4 weeks with a view to having 2 weekly calls in the
    morning European time [recorded in
    [40]http://www.w3.org/2008/10/21-bpwg-minutes.html#action01]

    <trackbot> Created ACTION-870 - Liaise with Seungyun and Jonathan re
    setting up a call in 4 weeks with a view to having 2 weekly calls in
    the morning European time [on Daniel Appelquist - due 2008-10-28].

Mobile Web for Social Development (MW4D) Presentation

    steph: Some background information...
    ... 1.5bn web users in the world; 4.5bn to go
    ... biggest hole in Africa

    jo: (and Greenland!)

    steph: particulary the poorest on <US$2/day
    ... The point isn't to connect people to the web; the point is
    access to essential services
    ... There are two trends:
    ... 1 is to provide low-cost laptops and internet connections

    <dom> [41]Stéphane's slides on MW4D

      [41] http://www.w3.org/2008/10/sb_mwbp/

    steph: 2 is to use mobile phones; 3.5bn people have access to a
    mobile phone, 80% of the population is covered with GSM signal
    ... Some impressive success stories, eg farmers finding markets for
    their produce instead of vice-versa

    <jo> [stephane pumps m-pesa ...]

    steph: So how can we help and encourage development of access to
    such services?
    ... Four strands: 1) understanding the technology channels; 2)
    people from these communities who know the needs, education issues
    etc;
    ... 3) the tools to support these people and 4) raising awareness of
    the whole issue and who can help
    ... The MW4D group runs to June 2009
    ... and expects to produce a handbook
    ... and a roadmap for actions for organisations that will lower
    barriers to MW4D
    ... and to identify a set of resources for all the players
    ... There is already a MW4D Factsheet available to everyone

    [42]http://www.w3.org/2008/MW4D/

      [42] http://www.w3.org/2008/MW4D/

    scribe: The heart of the group at the moment is the wiki (link from
    the homepage above)
    ... There have been workshops in India and Brazil so far, the next
    will be in Africa

    jo: Is the BBC involved?
    ... Lots of their mobile traffic is from Africa

    steph: not yet!

    dka: Is there any way BPWG can help?

    steph: we're not gathering training material yet - but clearly
    mobile web is one channel and ths will be coming soon

    jeffs: This is an issue I want to push - a broad base of people who
    know how to make these services will drive this

    hendry: how did it become *mobile* web?

    dom: the web foundation programme "Web for Society" is broader

    steph: have to recognise the idea of an Internet cafe in some places
    doesn't exist
    ... but GSM penetration is good in these places
    ... Even the needs of electricity for mobiles vs Internet PCs are
    fundamental

    dka: Remember Mobile Tech for Social Change in San Francisco on US
    Election Day

    <DKA> [43]http://barcamp.org/MobileTechForSocialChangeSanFrancisco

      [43] http://barcamp.org/MobileTechForSocialChangeSanFrancisco

    <DKA> (sign up now!)

    steph: The huge plus point for mobile services is that you can build
    them on an existing platform

Addendum to the Mobile Web Best Practices (BP1.5)

    <Kai>
    [44]http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/att-0001
    /ED-mobileOK-pro10-tests-20080731.htm

      [44] 
http://lists.w3.org/Archives/Public/public-bpwg/2008Oct/att-0001/ED-mobileOK-pro10-tests-20080731.htm

    Kai: We've reduced the test-like language in the document and moved
    it to an addendum

    <dom> "mobileOK best practices" don't exit; we have "mobileOK Basic
    Tests" and the "Mobile Web Best Practices"

    Kai: So the purpose (of the addendum) is now more precise
    ... Test format pass/fail/warn criteria are removed
    ... and tests are now evaluation criteria
    ... Now does the group have any feedback on this?
    ... since te group previously asked for this change

    <dom> [I certainly prefer the new format and orientation]

    jo: I think this doc needs to be an addendum to MWBP but I don't
    think it has much (or anything) to do with mobileOK
    ... these evaluations apply not just to mobileOK but are more widely
    applicable
    ... for example if people see this as a supplement to mobileOK
    (which is only about the DDC) then some of the contents will be
    confusing
    ... for example some of this document is useful for an iPhone
    experience which is not likely to be mobileOK

    Kai: where (aside from the title) are the strong references to the
    mobileOK Basic Tests?

    jo: the BP doc itself loosely contains tests
    ... the introduction links to this doc

    Kai: Jo, can you please provide clearer text for the introduction?

    <Zakim> dom, you wanted to ask what will be done when mobileOK basic
    defines a DDC-independent test (e.g. images_specify_size)

    dom: the switch from test to evaluation is an improvement

    <DKA> +1 to Dom - moving to "evaluation" from "test" a good step.

    <DKA> �1 to Jo

    dom: avoiding reference to checker and mobileOK is nore difficult
    ... eg best practices on image sizes are impossible to talk about
    without having a device in mind

    dka: I don't see the need to expunge references to mobileOK basic
    ... nobody's going to mistake the references to mean it's normative

    Kai: I agree with Dan, I don't see the risk
    ... and I see advantages in cross-refererences in this family of
    documents

    francois: The Purpose section can clarify this - the rest of the
    document can still include references

    jo: Now think this document should be titled "Supplementary
    evaluations for mobileOK Basic" (!!!?!)

    francois: mobileOK Basic is based on DDC

    jo: What's the "call to action" with this document?
    ... ie what are we asking people to do here?

    Kai: the Purpose states this
    ... it is to provide guidelines on how to get better than mobileOK
    Basic

    jeffs: and it is stuff that requires human intervention, it isn't
    machine-testable

    dom: These aren't "guidelines" though, they are "evaluation
    procedures"

    dka: We're not setting this up as mobileOK Pro though - that isn't
    clear

    francois: I prefer Jo v1
    ... we're adding to the lack of clarity about what relates to what

    <DKA> PROPOSED RESOLUTION: The group agrees with the approach to BP
    1.5 started by Kai.

    francois: so clarification of the Purpose and the relationship
    between the 3 documents is most important

    <DKA> PROPOSED RESOLUTION: The group agrees with the approach to BP
    1.5 proposed by Kai (removing "test" language and positioning it as
    an addendum to BP 1.0).

    <jeffs> +1

    Kai: I'm not sure these evaluations are completely separate from the
    DDC

    <nacho> +1

    <abel> +1

    +1

    <DKA> PROPOSED RESOLUTION: The group agrees with the basic approach
    to BP 1.5 proposed by Kai (removing "test" language and positioning
    it as an addendum to BP 1.0). Jo to work with Kai on clarifying 1.1
    "Purpose" and present back to group.

    <jeffs> +2

    <francois> +1

    +1

    <Kai> +1

    <dom> ACTION: Jo to work with Kai on clarifying purpose text of bp
    1.5 [recorded in
    [45]http://www.w3.org/2008/10/21-bpwg-minutes.html#action02]

    <trackbot> Created ACTION-871 - Work with Kai on clarifying purpose
    text of bp 1.5 [on Jo Rabin - due 2008-10-28].

    <abel> +1

    RESOLUTION: The group agrees with the basic approach to BP 1.5
    proposed by Kai (removing "test" language and positioning it as an
    addendum to BP 1.0). Jo to work with Kai on clarifying 1.1 "Purpose"
    and present back to group.

    <nacho> +1 (CTIC is very happy with the great work from Kai pending
    editorial issues)

    Kai: Scope needs to change as well then

    jo: Yes; we'll cover that in this review
    ... There is naff-all point in doing further work on this doc unless
    the group reads and reviews it

    dom: I can reformat the main body of the document if it's not going
    to change

    <dom> ACTION: Dom to work on reformulating 4 "tests" of BP 1.5
    [recorded in
    [46]http://www.w3.org/2008/10/21-bpwg-minutes.html#action03]

    <trackbot> Created ACTION-872 - Work on reformulating 4 \"tests\" of
    BP 1.5 [on Dominique Hazaël-Massieux - due 2008-10-28].

    dom: can I start on the two tests and pass them back for review?

    Kai: Yes, thanks

Mobile Web Application/s Best Practices

    adam about to present his documents with discussion points about the
    BP2 document

    <jo> PROPOSED RESOLUTION: The name of the document is: Mobile Web
    Application Best Practices

    <DKA> +1

    <jeffs> +1

    <rob> +1

    <SeanP> +1

    +1

    RESOLUTION: The name of the document is: Mobile Web Application Best
    Practices

    <jeffs> +1

    <aconnors> [47]Latest Editor's Draft of MWABP

      [47] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081008

    aconnors: some questions after comments in the document I am using
    to present
    ... better to start by top level headings and refactor the doc and
    see if there is something important missing
    ... some text on SVG from Abel
    ... does that sound a reasonable plan?
    ... personalization, retaining info between sessions
    ... dimishing the need for user input
    ... sensibility to network connection quality
    ... section on conservative use of resources

    [reading through the google doc...]

    <aconnors> [48]Adam's List of Issues

      [48] http://docs.google.com/Doc?id=dft77cn8_25gc7r7kcv&hl=en

    scribe: yellow section treated in the last F2F; need for refactoring
    ... some formal resolutions needed
    ... one web section, wondering whether this is a top leve section
    ... UI section, maybe needs refactoring... some stuff needs more
    level of detail, maybe some additions

    Jo: Input from the Korean TF needed

    [aconnors adds it to the google doc]

BP2 - One web section

    jo: intent of One Web section?

    aconnors: thematic consistency, basically
    ... my concern is that the top level headers are not appropriate and
    consistency of the documents in itself and against the BP 1.0

    [someone please correct the scribe on his mistakes]

    jo: more than editorial work needed.. there are stuff here that we
    did not have in BP1.0... a lot more practical stuff

    [nacho please asks people to speak a bit louder (not adam and jo :-)
    )]

    aconnors: adding a section in the gDoc on User Experience,
    mentioning One Web issues within it

    <DKA> PROPOSED RESOLUTION: In BP2.0, "user interface" section
    becomes "user experience" and "Offer A Consistent View Across
    Multiple Devices" section goes into "User Experience"

    <DKA> PROPOSED RESOLUTION: In BP2.0, "user interface" section
    becomes "user experience" and "Offer A Consistent View Across
    Multiple Devices" section goes into "User Experience" (thereby
    removing "one web" ase a top section).

    hendry: I see UI as HTML+CSS thing

    [anybody improving my scribing on KHendry?]

    +1

    <DKA> +1

    <SeanP> +1

    <jo> +1

    hendry: i do not see the sense of the One Web issue

    DKA: it is an important preamble

    francois: how about a first preamble on One Web and then insisting
    and clarifying within the User Experience subsection?

    DKA: right
    ... but let's get into resolutions

    RESOLUTION: In BP2.0, "user interface" section becomes "user
    experience" and "Offer A Consistent View Across Multiple Devices"
    section goes into "User Experience" (thereby removing "one web" ase
    a top section).

    <jeffs> +1

BP2 - Conservative use of resources

    dka: conservative use of resources... from an operator perspective,
    as more users reach plain data rates it might not bring benefit to
    operators but it does to the user.. although it fosters the usage of
    mobile web so in the end it is a win-win

    jo: responsiveness is a key point here... smaller apps being
    rendered faster

    aconnors: i agree but hard to word it

    dka: i volunteer to do that

    <scribe> ACTION: DKA to provide some words on conservative use of
    resources [recorded in
    [49]http://www.w3.org/2008/10/21-bpwg-minutes.html#action04]

    <trackbot> Created ACTION-873 - Provide some words on conservative
    use of resources [on Daniel Appelquist - due 2008-10-28].

    [phillip hoschka introducing himself]

    [Rotan hanrahan doing the same]

    aconnors: we should recap on where we are not, rather than start
    refactoring the doc

    jeffs: about user awareness and control, it should talk about the
    user retaining control on his PIM

BP2 - 3.8.3 Use Device Classification to Simplify Content
Selection/Adaptation

    aconnors: renaming "personalization" section into "retaining
    information on personalization"
    ... "handling device capabilit variation" section, need for
    explaining the need for device clasification to facilitate
    adaptation

    dka: referring contributions in the mailing list about device
    capability and also section 3.8.3 of the current draft of the BP2.0
    doc

    jo: original intention in my mind of this section is device
    clasification in terms of not having classes so use your own
    classification (but do it)

    Rotan: we had a little bit progress about classification (Structures
    oldie document) and the idea is to write device classification so
    others can read it... usage of ontologies for modelling that
    ... the definition itself is up to the web developers and other
    stakeholders, but it has to be made in a way that can be understood
    by others
    ... there is a bit of art in this process so it is impossible to
    "standardize" on what a tablet, or a smartphone is

    jeffs: conversation with blind people made me think about this...
    maybe the most important are things like input mechanisms

    rotan: if your focus is accessibility, you'll classify based on
    multimodality and other issues of interest for accessibility
    ... but others interested in other issues than accessibility will
    create other categories

    dka: let's focus on the doc
    ... maybe examples of categorization needed in the terms in the
    current draft (good, better, best bullets in the draft BP 2.0 doc)
    ... maybe reference DDR work as the source for classification
    information

    <DKA> PROPOSED RESOLUTION: In BP2: Group agrees with the approach
    taken in 3.8.3 - provide examples of classifications but do not
    define classifications.

    nacho: yes to classification in the bp2.0 just in terms of
    examplification... and clarifying this

    +1

    <rob> +1

    <abel> +1

    <jeffs> +1

    <SeanP> +1

    <Kai> +1

    <DKA> +1

    RESOLUTION: In BP2: Group agrees with the approach taken in 3.8.3 -
    provide examples of classifications but do not define
    classifications.

BP2 - 3.8.5 Provide for Both Graceful Degradation & Progressive
Enhancement of CSS

    aconnors: graceful degradation... more detail than what we might
    need in this section sometimes

    <scribe> ACTION: aconnors to refine the wording on graceful
    degradation trimming and making more explicit the text [recorded in
    [50]http://www.w3.org/2008/10/21-bpwg-minutes.html#action05]

    <trackbot> Created ACTION-874 - Refine the wording on graceful
    degradation trimming and making more explicit the text [on Adam
    Connors - due 2008-10-28].

    hendry: what about fallbacks? (when some feature is missing)

    [nacho can barely hear jeffs]

    jeffs: should encourage graceful degradation... when some technology
    is not supported, provide an alternative content/app to the
    browser.. exploit device capabilities that the server side knows
    somehow

    hendry: i'd like some words about AJAX here

    aconnors: the concept is like the one in google web toolkit... some
    JS to detect stuff and then the "real" JS for what the browser
    actually has to do

    jeffs: not just degrade, also talk about enhancing in the doc

    aconnors: it is useful to recommend to take decisions on the device
    too (not only server-side)

    jeffs: for example, i am offline so proceed accordingly

    jo: there are deeper underlined questions, about what is the
    guidance promoting here

    [nacho begs on his knees to jo to scribe his words later as it was
    hard for him to follow his words]

    Jo: any assessment you make about the norm is prejudiced by the
    market you're in, who you're trying to serve, etc
    ... your judgment is likely to be fragile in any case
    ... so the best advice to give is to tell people to take this into
    account

    adam: should the section on handling devices variation have guidance
    on what kind of detection to trust?
    ... e.g. favor server-side detection, and fall back to on-device
    decision
    ... including things that can not be determined a priori
    ... would be good to identify which of these priorities are

    Jo: e.g. battery level, signal coverage

    JeffS: I think pushing for graceful degradation is important
    ... we should advice developers to be prepared to vary based on
    their mid-point device

    Adam: you can do adaptation by having a script that adapts given
    values to the devices that host it
    ... or have different bundle of javascript/stylesheets served on a
    device per device basis
    ... do we want to promote one over the over?
    ... it seems like something that is extremely dependent of the
    applications

    Jo: we can point out the trade off
    ... although developers would more likely to be looking for more
    concrete advices

    DKA: still think it's worth highlighting
    ... if we discuss it more

    Jo: we need to point out the variables: time to download, latency,
    ...

    Adam: the cost of maintenance is also an important one
    ... so we would refactor 3.8.5 to say to favor server-side
    capabilities detection
    ... take into account that some capabilities cannot be determined
    server side
    ... balance adding device conditional statements to a single
    applications vs having different bundles per devices or devices
    classes

    <DKA> PROPOSED RESOLUTION: BP2 - refactor 3.8.5 to prefer
    server-side capability detection ; in some cases, client side cap
    detection is necessary, in which case: balance adding device
    specific statements into a single applications or having different
    modules / bundles ...

    DKA: "some of my best friends are media queries"

    <aconnors> PROPOSED RESOLUTION: BP2 - refactor 3.8.5 into the form
    of 3 recommendations: 1) prefer server-side capability detection ;
    2) in some cases, client side cap detection is necessary (example);
    3) balance adding device specific statements into a single
    applications against serving separate device-specific modules /
    bundles.

    <nacho> +1

    <DKA> +1

    <aconnors> +1

    <jo> +1

    <jeffs> +1

    <francois> +1

    <abel> +1

    RESOLUTION: BP2 - refactor 3.8.5 into the form of 3 recommendations:
    1) prefer server-side capability detection ; 2) in some cases,
    client side cap detection is necessary (example); 3) balance adding
    device specific statements into a single applications against
    serving separate device-specific modules / bundles.

Device Description Repository (DDR) Simple API interlude

    Rotan: after many years of work, the DDWG is coming to a close
    ... the charter concludes at the end of this month
    ... hopefully coinciding with the publication of the DDR API as W3C
    Rec
    ... the API comes with a core vocabularies that contain essential
    properties for basic content adaptation, particularly in the mobile
    space
    ... but it is only illustrative
    ... it defines properties such a height, width, accepted mime types
    ... you can use these properties to query the repository
    ... which can run in front of any kind of system (e.g. a database)
    ... The API is a server-side API, described for the Java language
    but usable in a variety of other languages, incl. IDL, WSDL, C#
    ... the API is expected to be used by anybody providing adaption
    technologies
    ... the existing solutions operate in silos
    ... we're hoping this group will be able to refer to this API when
    talking about adaptation
    ... This API is qualified as "simple", and is quite easy to
    implement
    ... it can serve as an illustration of what more complex systems
    could do
    ... There are other ways to do adaptation: DCCI (developed by the
    DIWG/UWAWG)
    ... that maps devices capabilities into a DOM structure available to
    javascript
    ... there is OMA's DPE (Device Profile Evolution), where a server
    and a device work in concert and enables the server to retrieve
    information from the server on the fly
    ... e.g. whether the user has turned the sound off
    ... so useful for information not available a-priori (thus not
    relevant for the DDR use case)
    ... The vocabulary is defined in a very simple way, with references
    to simple type (string, booleans, etc)
    ... it doesn't have a formal definition for its concepts, though
    ... we're hoping that the ongoing work in UWA to provide a common
    ontology could be used to provide formal semantics for our
    vocabulary
    ... We expect new vocabularies will be created - e.g. the Korean
    market place could use a new vocabulary for its use
    ... The danger might be that without a common ontology, digression
    between these vocabularies could appear
    ... so having this common ontology with units, dimensions of
    scripts, etc is critical

    <abel> Delivery Context Ontology latest public
    draft-->[51]http://www.w3.org/TR/dcontology/

      [51] http://www.w3.org/TR/dcontology/

    Rotan: We will be keeping our Wiki alive even after the end of the
    group's charter
    ... with commitment from editors to maintain it

    Seungyun: where are the existing implementations of the API?

    Rotan: there is a Java module derived from the spec
    ... available to developers
    ... there is also an IDL description, and OWL description, coming a
    c# description

    <francois> [52]Java representation of the DDR Simple API

      [52] 
http://www.w3.org/TR/2008/PR-DDR-Simple-API-20080917/DDRSimpleAPI.jar

    DKA: so UWA has a work item to continue some of your work?

    Rotan: yes, the ontology is a continuation/complement of our work
    ... it should be usable to formally define our core vocabulary
    ... and should reduce the risks of incompatibilities across
    vocabularies

    Jo: what's the ETA for the first version of the ontology?

    Rotan: UWA is meeting at the end of the week - would know more
    afterward
    ... we're hoping to have a sufficiently clear ontology in the next 6
    to 12 months to describe the core vocabulary
    ... but we need it to work across the various ubiquitous web
    applications
    ... I intend to continue pushing for this work in UWA

Liaison with ETSI - Statement from Bruno

    Bruno wants us to review the work of ETSI

    Jo: [reads statement]

    <jo> text from bruno:

    <jo> A team of mobile usability experts in ETSI Human Factors I am
    leading are

    <jo> developing a set of guidelines for generic user interface
    elements for

    <jo> 3G/UMTS mobile devices, services and applications.

    <jo> Detailed information and an earlier draft is available at

    <jo> [53]http://portal.etsi.org/stfs/STF_HomePages/STF322/STF322.asp

      [53] http://portal.etsi.org/stfs/STF_HomePages/STF322/STF322.asp

    <jo> The work provides:

    <jo> 1) Infrastructure and device-related guidelines:

    <jo> 2) Guidelines for services, media and applications: and

    <jo> 3) Guidelines for other (related) areas.

    <jo> A topic of 2) is "Mobile Internet access and development
    guidelines", where

    <jo> deliverables are a strong reference and starting point.

    <jo> This and possibly, several other topics addressed may be of
    interest to MWBP

    <jo> experts. We'd like to warmly invite those interested to review
    the stable

    <jo> draft (to be released by the end of the week) and provide their
    comments and

    <jo> feedback.

    <jo> An availability announcement will be made to the list(s).

    <jo> For further information and any questions, contact
    bruno@vonniman.com"

    Jo: It is likely that there are some things in here that apply to
    Mobile Web Best Practices

    Jeff: Seems like a short amount of time to review
    ... Is is Ok to share this with some of the ACI folks?

    <jo> ACTION: Jeff to scope current draft and see what aspects may be
    of interest to us. [recorded in
    [54]http://www.w3.org/2008/10/21-bpwg-minutes.html#action06]

    <trackbot> Sorry, couldn't find user - Jeff

    Jo: I think it is in the public domain.

    <jo> ACTION: Sonstein to scope current draft and see what aspects
    may be of interest to us. [recorded in
    [55]http://www.w3.org/2008/10/21-bpwg-minutes.html#action07]

    <trackbot> Created ACTION-875 - Scope current draft and see what
    aspects may be of interest to us. [on Jeffrey Sonstein - due
    2008-10-28].

BP2 - 3.8.4 Provide Alternatives to Client-Side Scripting

    Adam: Continuing the theme of handling device definition variability
    ... The question is do we want to say "Provide Alternatives to
    Client Side Scripting"
    ... My concern is that no all devices can do this. It may just be
    ignored if people can't follow it.
    ... Not all apps have non-scripting counterparts.

    DKA: Could we say something that if your app must have Javascript,
    we give them a nice message.
    ... The "upgrade your browser" message is not great, but better than
    junk on the screen.

    Adam: What is the recommended response?

    Jo: use 406 response
    ... message goes in the body.

    Rotan: Sometimes the error message itself is a source of errors.

    DKA: Error message should be mobileOK.

    Francois: Not all mobile browsers handle 406. This could confuse the
    user.
    ... Some browsers just say there is a connection problem.
    ... just a generic error.

    Jo: Isn't it better practice to send a response "javascript not
    supported"?

    Adam: No, we want to prefer server side detection.
    ... For an app that requires JS, it is best just to say "Your device
    cannot support this app."

    Jo: 406 is the right option.

    Francois: Unfortunately, it is problematic for some browsers.

    Jo: How about 200 response with an auto-refresh to a 406.

    Adam: Should I put in 406 for now?

    Jo: How about a placeholder for now.

    Jeff: A point of tension here.

    Kai: We are dealing with possible bad app design. May be a bad
    assumption that a device has JS.

    Jo: What about a game that requires JS?

    Adam: Not all web apps can work without JS.

    Kai: shouldn't have a link to the app in the first place.

    Jo: What if my friend sends a link.

    Jeff: I think a message to the user would be best.

    Kai: What about the <noscript> element.

    Adam: You might have to download something large to find the
    <noscript>
    ... May be better to detect at the server side.

    Jeff: Should we list out the cases?

    Adam: Could be a separate BP: Always include <noscript>

    Jo: Need to separate cases where JS is not supported and where it is
    turned off.

    Adam: I was think of just a simple BP where <noscript> should always
    be included.

    <jo> PROPOSED RESOLUTION: Include noscript wherever you have script

    <aconnors> +1

    <rob> +1

    RESOLUTION: Include noscript wherever you have script

    <jeffs> +1

    <aconnors> PROPOSED RESOLUTION: Change 3.8.4 Provide alternatives to
    Java-Script to be "Return 406 if you detect on server that
    javascript not supported" -- with a note that if a non-javascript
    counterpart to your application can possibly be supported this is of
    course desirable.

    Jeff: What happened to the <noscript>?

    Adam: separate resolution.

    Jo: <noscript> is for if JS is turned off

    <aconnors> PROPOSED RESOLUTION: Change 3.8.4 Provide alternatives to
    Java-Script to be "Return 200 and provide explanatory note +
    navigation if you detect on server that javascript not supported" --
    with a note that if a non-javascript counterpart to your application
    can possibly be supported this is of course desirable.

    Jo: We should say return 200 instead of 406 since we are a BP group,
    not a theory group. Include an informative note.

    Rotan: Wouldn't a good CT be able to adapt a 406 to a 200?

    Jo: Good point.

    Jeff: If there is CT, here is the route you take, if not here is the
    route you take.

    Jo: Unless you know the 406 will be handled, return a 200.

    Kai: Search engine will be confused by a 200 and think it is a real
    page. Best to use real error code.

    Francois: But we are talking about user experience.

    <aconnors> PROPOSED RESOLUTION: Change 3.8.4 to: Ideally support a
    non-javascript version of the application. If there is no sensible
    non-javascript counterpart, inform the user with: 406 if you are
    confident end-user will receive the message, 200 and explanatory
    note if not.

    Kai: We had this exact problem where 200 error messages were being
    indexed.

    <jo> +1

    <rob> +1

    <nacho> +1

    <abel> +1

    RESOLUTION: Change 3.8.4 to: Ideally support a non-javascript
    version of the application. If there is no sensible non-javascript
    counterpart, inform the user with: 406 if you are confident end-user
    will receive the message, 200 and explanatory note if not.

    <jeffs> +1

    <DKA> +1

    Jo: we now have 406 error support.

BP2 - 3.8.2 Use Reliable Methods for Determining Script Support

    Adam: 3.8.2 User reliable methods to determine script support. Do we
    want to reword this?
    ... seems like a loaded statement.
    ... maybe this gets absorbed in the previous resolution.
    ... I suggest that 3.8.2 will go away to become a part of 3.8.6.

    <jeffs> PROPOSED RESOLUTION: merge 3.8.2 and 3.8.6

    <jo> PROPOSED RESOLUTION: Fold section 3.8.2 into subsequent
    sections where is is more naturally covered

    <rob> +1

    <jo> +1

    <jeffs> +1

    RESOLUTION: Fold section 3.8.2 into subsequent sections where is is
    more naturally covered

    PhilArcher: Still interested in BPWG, but as able to contribute.

    Adam: Would like to receive feedback on the new sections: user
    interface and latency.

    Jo: Let's do user interface.

BP2 - 3.7 User Interface

    Adam: 3.7 user interface.
    ... Is there anything we want to add to this?
    ... covers both UI things and using things like URI schemes, etc.
    ... Any comments on these BPs?

    <aconnors>
    [56]http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/E
    D-mobile-bp2-20081008

      [56] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20081008

    Jeff: We're encouraging them to use scripting.

    Adam: BP1 is targeted at the DDC; this is targeted at something
    higher.
    ... In an ideal mode you'd have a JS and non-JS version so you'd
    pass BP1.

    Jo: Wording needs to be better, but no objections to 3.7.2
    ... Should say "If scripting is available then...". If not
    available, then ....

    Adam: There are a lot of BPs that assume scripting is available.

    Jo: Anything else on 3.7.2?

    Adam: would like the title to be better.
    ... current title seems broad.

    Jo: Seems true when we are trying to avoid latency.
    ... Can you wordsmith it?

    Adam: Don't have any particular opinions on this section, just want
    to discuss it because it is new.

    Kai: Has anyone talked to the Multi-Modal Interaction Group?
    ... The are focusing on the correct mode of input whatever the
    situation is.

    Adam: The focus of this document is say things like don't put links
    a long way apart if there is no pointing device.

    Jo: Could we go through this. Looks good. Avoid saying things like
    "more recent" to avoid dating it.
    ... We need to be clear on the words we use for markup--don't use
    "tags", use "elements". Use ECMAScript instead of JavaScript.

    Kai: We have some example code that uses ActiveX.

    Jo: This should be in an appendix.
    ... For 3.7.3, can we change "Don't Move the Focus" to "Maintain
    Focus"

    Jeff: How about "Preserve the focus"

    Jo: I thought this was about reflowing and keeping the focus from
    disappearing for a while.

    Adam: What is it we want to tell people to avoid?

    Jo: Use of the focus method is bad practice. Restore the focus to
    where it was if it goes away.

    Adam: We can reword it so that we preserve focus.

    <DKA> PROPOSED RESOLUTION: we agree.

    <jeffs> +1

BP2 - 3.7.5 Use hash URLs to Preserve Browser History and Enable Deep
Links

    Adam: On to 3.7.4
    ... 3.7.5

    Jo: Would "Provide direct links to embedded views" be a better
    title?

    Jeff: How about "internal links"?

    Jo: Title needs to change.

    DKA: I like "deep links"
    ... Web apps have a tendency to not allow deep links.

    Rotan: Need to be careful with deep links since they assume an app
    that is hierarchical, which is not always the case.

    Jeff: What about hash URLs?

    <DKA> [57]http://en.wikipedia.org/wiki/Deep_link

      [57] http://en.wikipedia.org/wiki/Deep_link

    Jo: Fragment URIs would be better terminology.

    Phil: I like "fragment URIs" because hash URIs is ambiguous.

    Jo: This would be a good one to have an example for in the appendix.

    <DKA> [58]http://en.wikipedia.org/wiki/Deep_link#Court_rulings

      [58] http://en.wikipedia.org/wiki/Deep_link#Court_rulings

    <jeffs> [59]http://en.wikipedia.org/wiki/Internal_link

      [59] http://en.wikipedia.org/wiki/Internal_link

    Adam: Should we have examples in an appendix?

    Jo: Yes.

    <aconnors> PROPOSED RESOLUTION: Change title of 3.7.5 to: Use
    Fragment URIs for Embedded Views

    <jeffs> +1

    <francois> +1

    <rob> +1

    Jo: I find 3.7.6 as overly UA-Prof oriented.

    RESOLUTION: Change title of 3.7.5 to: Use Fragment URIs for Embedded
    Views

    <aconnors> PROPOSED RESOLUTION: Add section to Appendix to for
    examples, and link to example for 3.7.5 here.

    <jeffs> +1

    <rob> +1

    RESOLUTION: Add section to Appendix to for examples, and link to
    example for 3.7.5 here.

BP2 - 3.7.6 Use URI Schemes for Device Functions

    Jo: This makes reference to WTAI and UAProf.
    ... Isn't this overly general?
    ... Actually what we are saying is to decorate telephone numbers
    with a tel: URI to facilitate click-to-call.
    ... WTAI as far as I am aware has limited implementation.

    Rob: More phones use wtai than use tel:, especially low-end
    handsets.

    Jo: There are lots of features of WTAI, like "put this in my address
    book" etc... How widely supported are those features?

    Jeff: Note that WTAI link doesn't point to the right place...

    Francois: I read a document (not W3C) mobile web best practices that
    most modern devices support both.

    DKA: (to Seungyun) do Korean browsers support tel:?

    Seyngyun: yes. We don't use WAP-related functions [such as WTAI].

    Jo: I think we should encourage the use of tel: because it's an RFC
    (RFC 3966).

    <jeffs> [60]http://www.ietf.org/rfc/rfc3966.txt

      [60] http://www.ietf.org/rfc/rfc3966.txt

    Jo: I don't think that the reference to UAProf is relevant.
    ... There are already references to UAProf to finding device
    capabilities.

    PROPOSED RESOLUTION: Change 3.7.6 - encourage use of tel: discourage
    use of wtai:. Eliminate reference to UAProf.

    <jeffs> +1

    +1

    <seungyun> +1

    <SeanP> +1

    <rob> +1

    PROPOSED RESOLUTION: Change 3.7.6 - encourgae use of tel: discourage
    use of wtai:. Eliminate reference to UAProf. Title should be "Enable
    'Click-To-Call'"

    <aconnors> +1

    <SeanP> +1

    RESOLUTION: Change 3.7.6 - encourgae use of tel: discourage use of
    wtai:. Eliminate reference to UAProf. Title should be "Enable
    'Click-To-Call'"

    <jeffs> +1

    Adam: Any other discussion around user experience?

    Dan: Support Scott's input on different input modes.

    Jo: Likewise.

BP2 - Latency

    Adam: Regarding javascript optimization -- it would be useful if
    anyone is an expert on eg. webkit -

    Jo: Maybe this could be a useful appendix?

    Adam: it will be a list of tips.
    ... Maybe this is too much detail?

    Jo: Where does application best practice stop and good programming
    style start?

    Dan: I think this is very important in the mobile context -
    developers need to know it because they might not consider these
    issues if they are used to desktop PCs...

    Jo: Impact on application-perceived latency and battery life of
    these kinds of optmiizations.

    Jeff: there is no imperical work on this afaik

    <scribe> ACTION: Adam to send to Jeff list of test cases that Jeff
    can inflict on a grad student. [recorded in
    [61]http://www.w3.org/2008/10/21-bpwg-minutes.html#action08]

    <trackbot> Created ACTION-876 - Send to Jeff list of test cases that
    Jeff can inflict on a grad student. [on Adam Connors - due
    2008-10-28].

    <JonathanJ> late comment for 3.7.6 - I think we need review this
    part of apple's document -
    [62]https://developer.apple.com/webapps/docs/documentation/AppleAppl
    ications/Reference/SafariWebContent/AppleApplicationsURLSchemes/chap
    ter_950_section_1.html#//apple_ref/doc/uid/TP40006513-SW1

      [62] 
https://developer.apple.com/webapps/docs/documentation/AppleApplications/Reference/SafariWebContent/AppleApplicationsURLSchemes/chapter_950_section_1.html#//apple_ref/doc/uid/TP40006513-SW1

BP2 - JSON vs. XML - the final conflict

    Jo: Are we advocating use of JSON over XML?

    Adam: JSON is far better than XML.

    Dom: I don't think anyone would object to saying "send a more
    compact format to a mobile device."

    Adam: Also it's quicker to parse JSON.

    PROPOSED RESOLUTION: We recommend to use a compact format (e.g.
    JSON) as opposed to a less compact one (e.g. XML) for XHR requests.

    PROPOSED RESOLUTION: We recommend to use a compact / natively
    processable format as opposed to a less compact one for XHR
    requests.

    Dom: Some javascript engines are starting to have a native JSON
    parser in them - but other than that the EVAL function is used which
    can be a security issue.

    <jeffs> +1

    Warning Warning Aooooga.

    Jo: 3 minute update coming up on POWDER. Then we can review
    proceedings and ajourn.

    Jo: In the next 10 minutes: POWDER, accessibility, next f2f, brief
    review of this meeting, wrap

Pre-discussion on Accessibility documents

    Jo: Yeliz's document is done.

    Jo: Re. Alan's document, situation is that it can't be brought to a
    conclusion yet because pending some resolutions in the Education and
    Outreach Working Group (EOWG)?

    Francois: The problem was the "addressing both" page.

    Jo: Either way, I'd like this work item to be concluded. If there's
    consensus on this, [I'd like to resolve] that we have made all
    contributions we are able to within this group.

    Dan: yes I'd like to take a resolution.

    Jo: We must verify with Shawn [from EO group].

    Jeff: Just so everyone knows - we [RIT] are interviewing people from
    various disabled groups....
    ... we are trying to come up with a set of recommendations to
    developers...
    ... could be made available to W3C as an input if they wish to take
    it up...

POWDER for mobileOK

    Phil: POWDER is based on the idea of labeling websites - reference
    TBL quote from 15 Sept 2008.
    ... We should be done by the end of this year.
    ... [presents description resource code] Any powder document must
    have an attribution element, and an issued by element. That links to
    somewhere. This is all XML. You can process powder in a pure XML
    environment without having to parse RDF.
    ... IRIset grouping [is the key part of the POWDER spec] - can be as
    complicated or simple as you like.
    ... [something complicated about math and logic]
    ... [presents MobileOK claim POWDER example]

    <dom> [63]mobileOK logo

      [63] http://www.w3.org/2005/11/MWI-Icons/mobileOK.png

    Phil: MobileOK claim can be transformed into an OWL document.
    ... You don't ever have to handle that - just showing OWL document
    to prove that it does have tha flexibility if needed.
    ... We MAY issue a 2nd last call this week.
    ... We will meet our CR exit criteria already [so we may move
    directly to PR].

    Rotan: One of the pieces of data in there is supported by: can you
    have multiple such?

    Phil: yes

    Jeff: Is there a schema?

    Phil: yes.
    ... Kevin Smith from Vodafone wrote it and it's really clever.

    <dom> [64]Powder WG home page

      [64] http://www.w3.org/2007/powder/

Accessibility documents

    follows [65]above discussion, in presence of Shawn and Andrew from
    the Education and Outreach Working Group (EOWG).

    Jo: 2 things - confirmed status update on documents from Alan and
    Yeliz and then where we go next

    Shawn: On "shared web experiences" document that Yeliz is doing -
    it's a WAI resource, not a note and not a doc so can be modified
    more easily [but is basically done] will be published soon.
    ... On the "relationship between..." document that Alan is working
    on - once WCAG 2 is finalized, we can go back to this document and
    be ready to call this done.

    Jo: What is the solution of the problem to the "together" section?

    Shawn: Alan said mapping is too complex to do a mapping table - so
    what can we tell people who want to do both? We agreed to tell
    people to first look at "shared web experiences" for an overview -
    next WCAG 2, then look at the mapping in this document between wcag
    2 and BPs, then look at the MWBP.
    ... Those steps are in the current version of the document. We will
    reword slightly.
    ... that's where EO is. Our question is: where are you [BP]?
    ... What level of review do you want to have at what point?

    PROPOSED RESOLUTION: We are happy with both documents. Any changes
    to Alan's document that will happen next will be as a result of
    changes to WCAG 2. In essence we are done.

    Shawn: With "shared experiences" we thought we were done and then we
    got a lot of comments... So a little considered that Alan's document
    hasn't got that level of review. I would like to go ahead and
    publish the version after this next set of changes since it's better
    than what's out there.
    ... we'll need Alan to make one more round of changes.

    Dan: I think we need to build some kind of review in for Alan's
    document.

    <francois> ACTION: daoust to create a poll on Alan's document once
    it's published as an updated working draft with a review period of 4
    weeks [recorded in
    [66]http://www.w3.org/2008/10/21-bpwg-minutes.html#action09]

    <trackbot> Created ACTION-877 - Create a poll on Alan's document
    once it's published as an updated working draft with a review period
    of 4 weeks [on François Daoust - due 2008-10-28].

Next F2F meeting

    Dom: Some budget issues coming up with regard to team participation
    in f2f meetings...

    Jo: We assume we will want to meet in June.
    ... Before then we will need to move to last call on BP2 sometime
    this year. We'll want to review lc comments sometime in the new
    year. CT will be through a 2nd last call by then. early new year
    would be a good option. February is a bad option ebcause of MWC in
    barcelona.
    ... March is too late.

    Dan: I don't think March is too late.

    Jo: yes it is.

    Dan: nu-uh

    [Discussing week of January 26th for next f2f meeting]

    [26th is national holiday in Korea - sunday, monday tuesday]

    Dan: Ok - week beginning Feb 2nd?

    [we will take resolution next meeting]

    <dom> ACTION: Francois to create a poll on having f2f in seoul on
    week of February 2nd [recorded in
    [67]http://www.w3.org/2008/10/21-bpwg-minutes.html#action10]

    <trackbot> Created ACTION-878 - Create a poll on having f2f in seoul
    on week of February 2nd [on François Daoust - due 2008-10-28].

Summary of Action Items

    [NEW] ACTION: aconnors to refine the wording on graceful degradation
    trimming and making more explicit the text [recorded in
    [68]http://www.w3.org/2008/10/21-bpwg-minutes.html#action05]
    [NEW] ACTION: Adam to send to Jeff list of test cases that Jeff can
    inflict on a grad student. [recorded in
    [69]http://www.w3.org/2008/10/21-bpwg-minutes.html#action08]
    [NEW] ACTION: Dan to liaise with Seungyun and Jonathan re setting up
    a call in 4 weeks with a view to having 2 weekly calls in the
    morning European time [recorded in
    [70]http://www.w3.org/2008/10/21-bpwg-minutes.html#action01]
    [NEW] ACTION: daoust to create a poll on Alan's document once it's
    published as an updated working draft with a review period of 4
    weeks [recorded in
    [71]http://www.w3.org/2008/10/21-bpwg-minutes.html#action09]
    [NEW] ACTION: DKA to provide some words on conservative use of
    resources [recorded in
    [72]http://www.w3.org/2008/10/21-bpwg-minutes.html#action04]
    [NEW] ACTION: Dom to work on reformulating 4 "tests" of BP 1.5
    [recorded in
    [73]http://www.w3.org/2008/10/21-bpwg-minutes.html#action03]
    [NEW] ACTION: Francois to create a poll on having f2f in seoul on
    week of February 2nd [recorded in
    [74]http://www.w3.org/2008/10/21-bpwg-minutes.html#action10]
    [NEW] ACTION: Jeff to scope current draft and see what aspects may
    be of interest to us. [recorded in
    [75]http://www.w3.org/2008/10/21-bpwg-minutes.html#action06]
    [NEW] ACTION: Jo to work with Kai on clarifying purpose text of bp
    1.5 [recorded in
    [76]http://www.w3.org/2008/10/21-bpwg-minutes.html#action02]
    [NEW] ACTION: Sonstein to scope current draft and see what aspects
    may be of interest to us. [recorded in
    [77]http://www.w3.org/2008/10/21-bpwg-minutes.html#action07]

    [End of minutes]
Received on Wednesday, 22 October 2008 10:38:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC