See also: IRC log
<achuter> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20080613/
dka: alan, could you walk us
through the current status?
... I'd like to get to the decision to publish a new draft of
this document.
... so, what I'd really like to know is what the status of the
doc is, and how EOWG feels about it.
alan: The overview document maps
to 5 other documents.
... the initial doc promoted the adoption of BP by, for
instance emphasizing that some of them also helped people with
disabilities
... but this was confusing, so we decided to split it up in two
different documents.
... The benefit part was moved to another document not referred
to from this document
<achuter> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-helps-20080612/
alan: This other document was
built on the ashes of the initial complete document, but is not
our main focus at the time.
... Back to the 13 June overview doc
... The structure is simpler, it needs to be reviewed, but it's
much more complete
alan: For instance, from MWBP to
WCAG 2.0
... Take a look at "Addressing WCAG 2.0 Success Criteria"
... You'll see the title of the SC, the definition, and what
you've already done for it if you've followed the BP
... It's much clearer now!
dka: and from WCAG 2.0 to MWBP, it's organized by best practices
alan: yes, it's organized by the recommendation you're moving towards, which makes more sense
dan: so what about the best practices that don't have any text? That's because they don't address any SC?
alan: yes, I guess we should remove them or annotate them in some way
dka: what do we still need to do?
alan: quite a few editorial
updates
... and the EOWG needs 2 more weeks to review the document
dka: are you pretty happy in terms of the current structure of the document and the number of documents?
alan: yes
dka: 7 documents?
dom: actually, it's just 7 pages of the same document
dka: OK, I was afraid this could lead to 7 TR documents
dom: no, only one
dka: what was the feedback from the EOWG on the structure?
alan: they like it better as well
<dom> http://www.w3.org/WAI/mobile/
<dom> http://www.w3.org/WAI/mobile/experiences
alan: the overview is short, but it contains before any other links 2 links to more detailed documents on the matter
<dom> [+1 on moving up the ToC just after the Status section]
alan: and we'll shift things around to have links moved to the top of the document as much as possible
[going through the two mentioned documents]
dka: has EOWG specifically required feedback from us on the document that compares mobile devices and people with disabilities?
alan: no, but that would be interesting
dka: it seems the best thing to do would be to action someone (not you alan) to review the document.
alan: yes.
... Another issue is how to do MWBP and WCAG at the same
time?
... It's fairly complicated to present both at the same time in
a document
dka: is this document part of the suite of documents?
alan: yes
... A lot of people have to do it: government sites for
instance have to do both
dka: stepping back for a second.
To move something to working draft, then I think we need to
consider this part as a stand-alone document, and publish the
rest.
... "When you have an elephant, you have to eat it one byte at
a time"
... issue a public working draft and having some press coverage
might be useful
... dom, do you think we could package this with the huge press
release we're about to make?
dom: well, it's going to be
confusing, at best
... I'm not sure press coverage is what we need. Blogging about
it. Also guys from CTIC which have a tool to help build such
content might be of some help.
dka: my suggestion is that we unlink this part from the rest, and that we publish the rest as a public working draft.
alan: right.
dka: We need to decide whether we need to omit the blank bits from the document or provide some text around the BP that don't have any SC match (and vice versa)
alan: I think it should just go as a list at the top of the page
dka: OK. Plus 2 weeks for the
EOWG to review. I'd like to be in a position to agree to
publish the doc on 26 June 2008.
... do you think you can address the bits we just talked about
in the next few days?
alan: yes.
jo: I'm midly concerned as dom, that the publication be buried if we publish it among many others.
dka: understood.
... alan, could you ask EOWG to ask us for feedback with a time
limit?
alan: yes
francois: wondering about the "do
it both" document. Shouldn't we leave it in as a placeholder to
ask for public feedback?
... It doesn't prevent publication as a Public Working
Draft.
... an we may still remove the page later on if we end up not
having time to work on it.
dka: agreed.
... alan, is everything clear?
alan: yes.
dka: congratulations alan. It's a lot of work, obviously, and pretty useful.
alan: thank you. It would be great if participants from the group could review the document. I understand we don't have time here to review it point by point.
dka: I was at a conference some weeks ago, and while mentioning the best practices, the first question I got was: "how does that relate with accessibility?"
dom: yes, I have the same question over and over again.
dka: in another conference, talking to people that are managing web sites for big companies, there was a lot of interest in both mobile and accessibility areas. In short, I think this document will be well received.
dom: The doc was published as
Last Call last week. One LC comment so far... er... mine.
... Basically, it's just more clarification on the
document
... and francois replied with suggestions that are close to
proposed resolutions.
... So, I'm still fairly optimistic that this Last Call will be
an easy one.
... I don't think we should resolve the items right now.
... 2 items to address: 1. the entrance criteria to Proposed
Recommendation phase. We have a test suite, we nearly have a
checker, and the remaining criterium is the 10 mobileOK highly
visible web sites.
... Jo created an issue re. that topic, we already have a few
sites, but I'm not sure we have 10 sites yet.
... and 2. discussion on mobileOK Scheme
dka: are we suggesting that we change the entrance criteria?
dom: no. I was just wondering if
people knew about some more web sites that could be part of the
list.
... One thing we haven't talked about is tools that produce
mobileOK, and as a matter of fact, I know about 3-4 tools that
produce mobileOK content
<dom> ISSUE-256?
<trackbot> ISSUE-256 -- Call for 10 mobileOK sites -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/256
dom: and that's even more important in my mind than the list of 10 web sites
jo: Could we make a statement to our HTML5 friends that objects processing is really hard?
<dom> http://www.w3.org/TR/2008/WD-html5-20080610/embedded0.html#the-object
jo: It's not clear to me when, from an architectural point of view, W3C recommends the use of adaptation on the client side.
dom: well, one of the goals of
HTML5 is that it explains how to process object elements
... one improvement that HTML5 brings is video, SVG embedding,
and the like, so you don't really need object elements in most
common cases.
... I'm not sure we have sufficient experience with this to
send something useful
jo: we've observed that it brings the issue of tasting content which is something you want to avoid in the mobile world.
dom: right, but there's a precise way to avoid that.
jo: not widely implemented
dom: right, but it exists.
<Zakim> francois, you wanted to mention XHTML2
francois: I just wanted to mention that XHTML2 generalized the fallback behavior of object elements to ANY element
dka: what is your plan to get 10 mobileOK web sites?
dom: well, content providers around the table may check that their highly visible web site is mobileOK for instance.
dka: could we create a contest of
some kind?
... same as the XPrize contest to reach space
<dom> http://lists.w3.org/Archives/Member/member-bpwg/2008Jun/0014.html
francois: wondering if we could go through the list and see how many mobileOK web sites we still need
dom: [going through the list and
emphazing the different sites and tools we already have]
... I think we already have a strong story to tell, but if we
could complete that list, that would be great.
dka: so, that's "great".
... what can we do today to create an action plan to reach the
target?
<dom> [checking http://www.bbc.co.uk/go/gmast/mob/-/mobile/ ...]
dka: I'm thinking about BBC for instance, that are very mobile-friendly, but that may just lack awareness on mobileOK and thus fail a bit. I would be happy to take an action to try to contact them.
<dom> [5 error types http://validator.w3.org/mobile/?docAddr=http%3A%2F%2Fwww.bbc.co.uk%2Fgo%2Fgmast%2Fmob%2F-%2Fmobile%2F ]
dka: Would other people be willing to do the same with other content providers?
dom: the twitter web site has only two minor errors. Anyone with contacts over there?
<dom> [2 very simple errors on m.facebook.com too http://validator.w3.org/mobile/?docAddr=m.facebook.com%2F ]
<dom> [http://validator.w3.org/mobile/?docAddr=http%3A%2F%2Fm.twitter.com ]
<scribe> ACTION: dan to contact BBC to see if they can make their mobile web site mobileOK [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action01]
<trackbot> Created ACTION-796 - Contact BBC to see if they can make their mobile web site mobileOK [on Daniel Appelquist - due 2008-06-25].
kai: would be worth contacting content providers that have only one or two errors. It doesn't cost much, and they would most probably appreciate the feedback.
<Kai_> test
[bruno introducing himself, ETSI, and liaison between W3C and ETSI]
<adam> Scribe: Adam
<scribe> ScribeNick: Adam
<dom> ScribeNick: adam
<Kai_> latest draft: http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080610
kai: Task Force has gone through
the document in detail. Status is now waiting for
feedback.
... Several questions that need to be answered. Discussions
this wk may have changed things.
... What kind of document should this be?
... What form of document is will impact overall message for
working group.
... Checker deals with machine testable part, this doc focusses
on human testable page.
... But because of this the tests we can run are
subjective.
... We have reworked tests to try and increase
repeatability.
jo: Lets run through document in detail to refresh our memories.
Kai: [ Describing Test Format
]
... For example, 4.1 Access Keys
<Zakim> jo, you wanted to mention the testing environment
jo: Test format is pretty clear, but test environment is missing. Some tests presuppose use of DDC and some don't, this is quite an intricate question.
Kai: Intention was to use DDC, but there is not an emulator.
jo: So there is a question of how tests are carried out. But there are also some tests which specify *not* using the DDC.
<dom> Test on device capabilities: http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080610#device_capabilities
jo: Recommending to test with a number of devices immediately makes the tests difficult to repeat.
<dom> PROPOSED ISSUE: What is the testing environment for mobileOK Pro: DDC or not, and if not, how does it affect repeatibility
dka: Key point is that if you are not using DDC then there is an issue with repeatability. Do we need an issue to track this.
kai: General thrust was to use the DDC emulator but we don't have it yet.
<dom> PROPOSED ISSUE: What is the testing environment for mobileOK Pro: DDC or not, and if not, how does it affect repeatibility
dka: We could consider restructuring document around: tests that use DDC, and tests that don't.
<dom> PROPOSED ISSUE: Which mobileOK Pro tests needs the DDC and which don't?
<dom> ISSUE: Which mobileOK Pro tests needs the DDC and which don't?
<trackbot> Created ISSUE-266 - Which mobileOK Pro tests needs the DDC and which don't? ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/266/edit .
<dom> ISSUE-266: in particular, when the tests require that it's not DDC, how does it affect repeatibility?
<trackbot> ISSUE-266 Which mobileOK Pro tests needs the DDC and which don't? notes added
kai: [back to Access Keys]
... This is about primary navigation links on the page. You
can't have access keys that change from page to page so only
makes sense to assign access keys to primary navigation
links.
... [Going through 4.1 Access Keys requirements]
jo: We all agree that access keys
are good, the difficult thing is to turn such things into
actionable statements.
... In web applications, for example, there are very few pages
so this might be a moot point.
... This might introduce too many caveats and cloud the
issues.
kai: Consistency can still be required in web applications regardless of whether or not there are multiple pages.
jo: Agreed. But the definition as
it is written doesn't capture the essence of this.
... We probably know what you mean by "Link declaration summary
page" but if we are making "pass/fail" demands a general
understanding isn't enough. We need to be more precise in the
language.
... The "identical across all pages" is probably not really
what you mean. This is very difficult to word in a way that
can't be refuted.
kai: We can't provide an exhaustive list of examples. What degree of detail do we need to go into?
jo: Agree. But how much should we provide is an open question. I am trying to anticipate the kind of comments we will receive on this.
[break for coffee]
kai: We will look at a few tests
to get a feel for the document and then lead back into the
broader discussions.
... 4.6 Device Capabilities is a good place to start
discussion.
... we cannot cover all possibilities and there may be devices
that have capabilities not supported by the DDC, so we have
turned this test around
... the test condition is that the content should not be
artificially limited to the DDC on devices that have greater
capabilities.
... for example, if the width is limited to the DDC
screen-width on devices that have more real-estate then this is
a fail.
jo: Under test procedure you
refer to "unadapted, original content"... The presupposes that
the original content wasn't intended for the DDC. Some more
careful wording is needed.
... this document needs to encourage people to think of mobile
representation as the natural one.
<SeanP> Scribe: SeanP
<scribe> Scribenick: SeanP
jo: Another comment: it is OK to offer an alternative to something like video to the DDC
kai: Alan had posted this comment
as well. [Comment made on the mailing list]
... 4.4 Background Image Readability
... patterned or photographic bg image discouraged but not
prohibited
... Use a test for color blindness that tests for color
contrast--test is fairly deterministic
jo: Is this an average contrast or each and every pixel?
kai: Each and every one.
... probably permissible to use the extremes.
... 4.5 Balance
... weren't exactly sure what to do with this test, so we just
picked a value.
... example is a sitemap--may have well over 30 links.
... how many links does the user have to click through without
being annoyed--30 was picked.
jo: Should make a note about the different navigation models for this test.
dom: Safe to assume that we are using a scheme that we have to go through every link.
dka: worth stating that we are using a nav model that requires all links to be traversed.
dom: this is a case where we need to make clear that there is no pointing device
kai: if we are going to redfine the DDC...
dka: not redefining--refining
kai: this is a big step...
dka: we want to say that the DDC
has a keypad and supports access keys
... and is focus based
kai: What is the feeling on a test like this where a number is just picked?
jo: We did that in other cases and we had justification in doing that--not arbitrary.
kai: Google had some information, but had some odd numbers.
jo: nytimes had 500 links on the home page.
kai: So is it OK to just pick a value?
dom: should be backed up by some
data.
... 30 is not a bad number.
jo: Shouldn't have to scroll over
more than 2 screens of links.
... could use this to compute a number.
kai: Could come up with a way to
construct a number, but would still be contrived.
... would be great to have data, but don't have it.
adam: Will check into whether Google has data on this.
<dom> ACTION: Adam to check on availability of data about the number of acceptable links in a focus-based browser [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action02]
<trackbot> Created ACTION-797 - Check on availability of data about the number of acceptable links in a focus-based browser [on Adam Connors - due 2008-06-25].
scott: Some devices could be 10 links, other devices could be 30 links because of differences in devices.
jo: We're assuming the DDC.
kai: Another example: 4.3 Avoid Free Text
<dom> [I think we should look at least at one test that already exists in mobileOK basic but that mobileOK pro completes]
kai: How do you deal with this?
There will be forms where you have to type in your name.
... think of anything where you have to type in an unknown
value.
... you can make lists of possible values. Where do you decide
when the list is too big?
jo: good example.
kai: Really cannot put a limit on these lists--just needs to be finite.
dom: Something around 30 should
be the max since you'll need to click through all of
them.
... should think of a way to trim the list if it is over
30.
... or use free text.
kai: 4.15 Deficiencies
... one of the wishy-washy tests that are difficult.
... how do you deal with future changes to devices?
... try to bracket the test to: look for deficiencies that
impinge significantly on the usability of the content being
offered.
dka: Out of time but these items
are good examples of the work that has gone into the
document.
... would like to have a plan for getting this document out
there.
... what do you think we should do, Kai?
Kai: Does the group think this
document make sense?
... we need feedback from the public. Should put it out there
as a public working draft.
dka: 2 questions to ask: Does the
material in the document make sense? Does the stated goal of
the document make sense?
... Is this a rec track document or a note? What should it be
called?
<dom> +1 on usefulness of the content of the document
dka: I think there is a lot of
valuable material in this, but these questions need to be
answered.
... I've already expressed some concerns about mobileOK Pro.
Some of the problems are extremely difficult. What you have
come up with could be extremely useful.
... Given the amount of work required, I don't think it is
reasonable to develop mobileOK Pro within the time left in the
charter.
<DKA> PROPOSED RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum...
<Zakim> jo, you wanted to support the notion that the content of the document is extremely useful and to add something to what Dom stole of my thunder and to add that Dom just stole that
dka: I suggest creating an addendum to another document like MobileOK Basic.
<DKA> PROPOSED RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum to BP 1.
<DKA> PROPOSED RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum/clarification/explanatory text to BP 1.
jo: Agree with Dom. Has been 18
months since BP 1 was released. Should be thinking about
releasing explanatory text about BP 1.
... This is would be useful for doing this.
<DKA> PROPOSED RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum/clarification/explanatory text to BP 1, closing the gap between BP1 and BP2.
kai: We have a big gap between BP 1 and BP 2. This document could be used as kind of a BP 1.5 to close the gap between BP 1 and 2.
<jo> +1 to what Kai just said
dka: I like the idea, don't support calling it BP 1.5.
<dom> (I think this relates to ISSUE-185)
<dom> ISSUE-185?
<trackbot> ISSUE-185 -- What are the mobileOK Full deliverables? -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/185
dka: I think it makes sense to have addendum to BP 1. Is it rec track or a note?
dom: 2 options: Add kind of an addendum to update BP 1 and clarify them, or create a new document.
kai: I think it would make the most sense to modify the current document.
<jo> -1 to a 2nd edition
dom: Probably the most logical solution even though it would be more work.
<jo> -1000000 to a second edition
<Zakim> jo, you wanted to think that it is too close to the publication of the BP doc to issue a 2nd edition
dom: Biggest problem will be resources.
jo: Don't have the time to work
on second edition of BP 1. Technically, BP 1 has not been
published.
... Best thing would be to issue a note.
... probably too close to publishing BP 1 as a rec to create a
second edition.
<Zakim> francois, you wanted to wonder about new BPs
jo: Best to let BP 1 be a rec by itself for a while.
dom: Rec always has a link to errata. One way to link to the mobileOK Pro stuff would be as errata.
<DKA> PROPOSED RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum/clarification/explanatory text to BP 1, closing the gap between BP1 and BP2. Also publish an errata.
jo: Value of this document goes further than errata.
<dom> "Success criteria for MWBP"?
kai: What about treating Pro as as supplement and putting a link in BP 1 to it.
dom: Could put a link before it goes to rec, but don't think this new supplement would be ready yet.
jo: Could link it as errata.
<Zakim> francois, you wanted to wonder about new BPs and comparison with WCAG 2.0 quickref
francois: Are we planning on adding new BPs for BP 1?
kai: Not new BPs, but were thinking of adding extensions for Pro, but decided not too.
francois: WCAG document had side companiion doc about how to meed the requirements. Could we something like that? May not have enough time.
<DKA> PROPOSED RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum/clarification/explanatory text to BP 1, closing the gap between BP1 and BP2 (and linked to from the BP1 Errata document).
Kai: Side companion OK, not a quick reference.
francois: WCAG quick reference is not really a quick reference.
kai: If we have another document that is a side companion some people will look at one and not the other.
dka: If we move Pro to being an
addendum, what happens to the Pro task force?
... I think it would make sense to bring this work into the
working group.
jo: Sure, why not?
kai: Every time we talk about this in group issues come up, so we might as well have all our discussions with the entire group.
<DKA> PROPOSED RESOLUTON: The group agrees to close the MobileOK Pro task force and bring the document (rebranded as BP1 addendum) into the main body of the working group. Kai to remain as editor.
kai: I can continue editing the document.
<DKA> PROPOSED RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum/clarification/explanatory text to BP 1, closing the gap between BP1 and BP2 (and linked to from the BP1 Errata document).
<DKA> PROPOSED RESOLUTON: The group agrees to close the MobileOK Pro task force and bring the document (rebranded as BP1 addendum) into the main body of the working group. Kai to remain as editor.
<dom> +1 on both
<adam> +1
<manrique> +1
<Kai_> +1
<Zakim> jo, you wanted to raise a point of order
<jo> +1 to both
RESOLUTION: Given the timeframe of the group, and the work required to make MobileOK real, we should not aim towards creating mobileOK Pro in this charter time. Rather we should reuse the material that has been produced in the MobileOK Pro TF in a new document, such as an addendum/clarification/explanatory text to BP 1, closing the gap between BP1 and BP2 (and linked to from the BP1 Errata document).
<DKA> PROPOSED RESOLUTION: The addendum to BP1 previously known as MobileOK Pro will be a working group Note.
<Kai_> +1
<dom> +1
<jo> +1
RESOLUTION: The addendum to BP1 previously known as MobileOK Pro will be a working group Note.
dka: One more mobileOK agendum: Scheme and Licensing.
RESOLUTION: The group agrees to close the MobileOK Pro task force and bring the document (rebranded as BP1 addendum) into the main body of the working group. Kai to remain as editor.
<dom> ISSUE-250?
<trackbot> ISSUE-250 -- The mobileOK License -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/250
dom: Issue 250
<Kai_> ACTION: Kai to work proposed changes into the mobileOK Pro document and then turn it over to the group [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action03]
<trackbot> Created ACTION-798 - Work proposed changes into the mobileOK Pro document and then turn it over to the group [on Kai Scheppe - due 2008-06-25].
<dom> Proposed licenses for mobileOK Basic
dom: mobileOK policy document
summary
... has the the mobileOK logo; protecting mobileOK in two ways:
trademark and copyright for the logo
... need to conform to spec to claim you are mobileOK.
dka: simple, thanks for W3C for registering mobileOK as a trademark.
jo: Still have the same problems
with this that we had a year ago.
... is not clear that mobileOK is on the representation of the
resource and not the URI.
... need to have the proper view on what mobileOK really
means.
<DKA> PROPOSED RESOLUTION: "This page" in the MobileOK license refers to a URI, not a representation.
dom: We need to be clear as a
group: My understanding that mobileOK refers to the URI and not
the representation.
... this is a legal document, not a technical one.
kai: I think that Jo's point was good.
dom: Should be on URI so you can put it on the desktop view.
RESOLUTION: "This page" in the MobileOK license refers to a URI, not a representation.
<JonathanJ> Should we need more clarification "mobileOK Logo" and "mobileOK Basic Logo" ? Can it be use in same condition ?
jonathan: mobileOK logo and mobileOK basic logo are different.
dom: since mobileOK Pro will no longer exist--mobileOK logo will be used for mobileOK basic.
<DKA> PROPOSED RESOLUTION: the MobileOK logo will be used to represent conformance to MobileOK Basic Test 1.0 - there will be One Logo.
<jo> +1
<DKA> +1
<rob> +1
<Kai_> +1
<dom> +1
<adam> +1
RESOLUTION: the MobileOK logo will be used to represent conformance to MobileOK Basic Test 1.0 - there will be One Logo.
dka: Is there small version of this logo?
<francois> [side node to jo: mobileOK Pro is mentioned in mobileOK Basic Tests document and will have to be removed (as a non-substantive change!) from the draft before it is published as a Proposed Recommendation]
<Zakim> DKA, you wanted to wonder about the mobile-friendliness of this logo...
dom: excellent question: some
people would like to different colors for the logo; I think we
released some ones in with other color schemes. We could
release several logos with different sizes, colors, formats,
etc.
... we can still amend the document to put in other logos.
<DKA> PROPOSED RESOLUTION: The group would like there to be multiple representations of the One MobileOK logo, including a version suitable for small screens.
<JonathanJ> I suggest to change: in Chater 3, "use the mobileOK�� Basic logo as linked" to "use the mobileOK�� logo as linked"
<dom> good point, JonathanJ
dom: Need to decide how we want to use the logo to promote mobileOK.
manrique: How does this relate to checker?
dom: You would prove to the W3C passed the checker and the W3C would allow you to use the logo.
francois: How about an SVG version so you could scale it to any size.
dka: Hasn't MarieClaire done some
logos?
... Lots of people I talk to want to make sure the logo will
fit on a small screen.
<Zakim> jo, you wanted to note ref the proposed resolution that the license advises that the logo should not be used on mobile pages
jo: The license contains the terms that you should not use it on small screens. Need to be clear on how we want to use it.
dka: Don't think the license
should address where the logo should be displayed.
... my point wasn't where the logo should appear--just that a
small version of the logo should exist.
ed: I think Chaals made that point that a favicon should exist for the logo.
<DKA> PROPOSED RESOLUTION: The group requests that the MobileOK License document not include language on whether or not to use it on a mobile device.
jo: Need to insert a note about this into the Scheme document. Should make sure that you only put the logo on the pages that are mobileOK.
<DKA> PROPOSED RESOLUTION: The group requests that the MobileOK License document not include language on whether or not to use the logo on a mobile device.
RESOLUTION: The group requests that the MobileOK License document not include language on whether or not to use the logo on a mobile device.
<jo> [my earlier point was that the presence of the mobileOK logo may alter the mobileOKness of the document]
MarieClaire: [Talking about mobileOK logo] Will have a small one (16x16).
dka: Is there an SVG version of the logo?
<JonathanJ> Do we need the international version of mobileOK license document ? (multi-language ?)
MarieClaire: Yes.
dka: The license document should include a link to the logos.
dom: Regarding Jonathan's point, legal documents are not translated. It could be translated, but the "real" one is the English one.
Time for lunch.
<edm> ISSUE-250?
<trackbot> ISSUE-250 -- The mobileOK License -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/250
<edm> scribe: edm
<scribe> scribenick: edm2z
<dom> ScribeNick: edm
dka: we need to revisit the checker licensing issue when the checker is ready
jo: ...at some point in
time
... the license needs to refer to A valid mobileOK
checker
... we have not resolved on what basis the checker is a
checker
dka: also need to look at items e/ and f/ of issue-250
jo: mobileOk claims would be made
without any proof that would support the claims...
... ... we need to make sure that checker license is worded
consistently
<jo> PROPOSED RESOLUTION: use of the mobileOK logo is a sign that there is a claim (or statement) that the URI (when resolved in the manner described in ...) will, from the start of the claim, forward in time (to some specified? point) yield a representation than passes mobileOK basic tests
dom: we should refrain from making any assertions about the duration of a claim
jo: mobileOk claim must be some
forward looking statemnt or else would be meaningless
... ...has to have some level of assurance that the claim would
remain valid for certain period of time
dom: section 3 of the mobileOk license states that the mobileOk string is to be used to make clains of conformance to the MOK Basic Tests 1.0 concerning a specific page...
jo: we need to be clear when the logo should/could be used and the link between the claim and the checker
<dom> PROPOSED RESOLUTION: we remain silent on the duration of claim and leaves that to judges to decide based on when/how the claim was made
jo: use of the MOK logo is not necessarily a claim
dom: MOK logo could be used only when bound to an URI
<dom> ACTION: Dom to get back to rigo on updating the mobileOK license [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action04]
<trackbot> Created ACTION-799 - Get back to rigo on updating the mobileOK license [on Dominique Hazaël-Massieux - due 2008-06-25].
francois: relationship between the checker and the MOK claims is already spelled out in the license
jo: we should clarify that each MOK test should be passed separately
<dom> PROPOSED RESOLUTION: the checker is only a way to be comfortable that you're not breeching the license terms, but doesn't serve as a proof
dka: now that we are done talking about license terms, lets talk about MobileOK Scheme
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/080408.html
Kai: notes that references to MobileOk pro may need to be removed
<jo> ACTION: Jo to remove references to mobileOK Pro in the mobileOK Basic Tests Document [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action05]
<trackbot> Created ACTION-800 - Remove references to mobileOK Pro in the mobileOK Basic Tests Document [on Jo Rabin - due 2008-06-25].
<rob> Scribe: rob
<scribe> ScribeNick: rob
<jo> PROPOSED RESOLUTION: Keep the name of mobileOK Basic Tests 1.0 the same
francois: need to remove reference to MobileOK Pro if we're not keeping it as a document
<Zakim> manrique, you wanted to keep mobileOK Basic as Basic, since it checks a small set of BP
jo: we can keep mobileOK Basic tests, because they are only tests of a subset of mobileOK!
manrique: exactly, the Checker only verifies a subset
jo: my concern on the Trustmark doc is that the use-cases and requirements shouldn't be in here
dka: somebody needs to remove a
lot of stuff, turning it into a wrapper doc for the other docs
about mobileOK (about 1/4 of current length)
... i can be the editor
jo: Chaals has volunteered to edit, he just needs the feedback
kai: also could reference POWDER
<DKA> PROPOSED RESOLUTION: the MobileOK Scheme document should be reduced to a "wrapper" document which will consist of pointers to MobileOK Basic Tests 1.0, Mobile Web Best Practices 1.0, the checker, the license rules and the logo usage page [and POWDER if appropriate based on a future decision on use of POWDER]. The document won't talk about certification.
<DKA> PROPOSED RESOLUTION: the MobileOK Scheme document should be reduced to an explanatory "wrapper" document which will consist of pointers to MobileOK Basic Tests 1.0, Mobile Web Best Practices 1.0, the checker, the license rules and the logo usage page [and POWDER if appropriate based on a future decision on use of POWDER]. The document won't talk about certification.
<DKA> PROPOSED RESOLUTION: the MobileOK Scheme document should be reduced to an explanatory "wrapper" document which will consist of pointers to MobileOK Basic Tests 1.0, Mobile Web Best Practices 1.0, the checker, the license rules and the logo usage page [and POWDER if appropriate based on a future decision on use of POWDER]. The document will remain silent on certification.
kai: is this doc becomming a "primer"?
dka: no, a primer would have more prose than we want here
jo: purpose is to show where everything you want to know about mobileOK is
<DKA> PROPOSED RESOLUTION: the MobileOK Scheme document should be reduced to an explanatory "wrapper" document which will consist of pointers to MobileOK Basic Tests 1.0, Mobile Web Best Practices 1.0, the Checker, the license rules and the logo usage page [and POWDER if appropriate based on a future decision on use of POWDER]. The document will remain silent on certification.
<DKA> PROPOSED RESOLUTION: the MobileOK Scheme document should be reduced to an explanatory "wrapper" document which will consist of pointers to MobileOK Basic Tests 1.0, Mobile Web Best Practices 1.0, the Checker, the license rules and the logo usage page [and POWDER if appropriate based on a future decision on use of POWDER] (and maybe a nice little picture). The document will remain silent on certification.
<DKA> +1
<francois> +1
<jo> +1
RESOLUTION: the MobileOK Scheme document should be reduced to an explanatory "wrapper" document which will consist of pointers to MobileOK Basic Tests 1.0, Mobile Web Best Practices 1.0, the Checker, the license rules and the logo usage page [and POWDER if appropriate based on a future decision on use of POWDER] (and maybe a nice little picture). The document will remain silent on certification.
jo: Dan, please convey our thanks to Chaals and convey our review feedback to him
<jo> ACTION: Dan to thanks Chaals for producing the draft of mok scheme, to apologise on the group's behalf for not responding sooner and to draw his attention to the resolution taken on its contents [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action06]
<trackbot> Created ACTION-801 - Thanks Chaals for producing the draft of mok scheme, to apologise on the group's behalf for not responding sooner and to draw his attention to the resolution taken on its contents [on Daniel Appelquist - due 2008-06-25].
<JonathanJ> http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/0052.html
<JonathanJ> http://lists.w3.org/Archives/Public/public-bpwg/2008Jun/att-0052/03._BP-KoreanTF-report-v1.0.pdf
<JonathanJ> this is my report file
<DKA> Korean TF Proposal: http://docs.google.com/View?docid=ddkw3489_18gg7zjk57
<edm> Gap analysis http://docs.google.com/Doc?docid=dhpvgnmn_53c7h2stfp&hl=ko
<edm> TF meeting minutes http://www.w3.org/2008/05/08-korean-minutes.html
<edm> ...and http://www.w3.org/2008/05/20-korean-minutes.html
JonathanJ: trying to have TF meetings bi-weekly
<edm> TF Roadmap: Requirements documents by the end of December 2008...
<edm> ...and Report documents by the end of December 2008.
jo: thanks for the clear TF report
dka: are all the Korean companies in the TF officially members of the W3C WG?
JonathanJ: yes
dka: Good, because they will need to rejoin the WG when we change our charter
francois: there are participants from NHN and TTA that are not WG members?
JonathanJ: they are W3C MWI participants but not BPWG members
<jo> ACTION: francois to follow up on status of Korean TF members in respect of W3C and WG membership [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action07]
<trackbot> Created ACTION-802 - Follow up on status of Korean TF members in respect of W3C and WG membership [on François Daoust - due 2008-06-25].
dka: they need to be wither BPWG members or Invited Experts so that the patent policy is tight
jo: suggest we don't do Issues and Actions today
dom: but everybody please look at your actions!!!
francois: when you've done your action, change the status to "Pending Review"
jo: last 2 items on today's agenda don't apply if we are rechartering.
kai: recent email from Phil -
documents on-track
... to go into last-call at the end of the month
... rather than going through the doc details, any
questions?
jo: will there be delays in review?
kai: don't anticipate delays because they have been well reviewed already
dom: you have to show implementations, do you know if there are any yet?
kai: several planned but none
existing yet
... we had some very large changes very late so documents have
to be finished before any implementations can be successful
dom: BPWG took a resolution in Boston to use POWDER
jo: don't we need to publish a vocabulary document?
kai: yes, it's a very small document, Phil is the editor
<jo> PROPOSED RESOLUTION: We will not have a separate mobileOK powder vocab document, its proposed contents will form part of the mobileOK scheme document.
<jo> +1
<dom> +1
<Kai_> +1
<DKA> +1
+1
RESOLUTION: We will not have a separate mobileOK powder vocab document, its proposed contents will form part of the mobileOK scheme document.
jo: well done so far!
<Kai_> ACTION: Kai to get the definitive mobileOK example from Phil Archer [recorded in http://www.w3.org/2008/06/18-bpwg-minutes.html#action08]
<trackbot> Created ACTION-803 - Get the definitive mobileOK example from Phil Archer [on Kai Scheppe - due 2008-06-25].
dka: this is about having a
mobileOK club - ie what can we do to promote the idea beyond
the logo on compliant sites
... we've already talked about having the logo outside of
web-pages today
jo: what about "I aspire to be mobileOK soon"?
<jo> PROPOSED RESOLUTION: Drop the idea of an aspirational level of mobileOK, it seems to be included in the current understanding of mobileOK logo usage rules
<jo> +1
<dom> +1
<DKA> +1
dka: nothing prevents us all blogging about it a lot!
<abel> +1
RESOLUTION: Drop the idea of an aspirational level of mobileOK, it seems to be included in the current understanding of mobileOK logo usage rules
jo: AOB?
<jo> PROPOSED RESOLUTION: BPWG Thanks W3C very much for its kind hospitality in hosting this F2F meeting
<DKA> +1
+1
<SeanP> +1
<jo> +1
<manrique> +1
RESOLUTION: BPWG Thanks W3C very much for its kind hospitality in hosting this F2F meeting