W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2009

Re: [minutes] 12 May 2009 Teleconference

From: Tom Hume <tom.hume@futureplatforms.com>
Date: Tue, 12 May 2009 23:34:04 +0100
Message-ID: <a293dbd10905121534pca5ba7bh7546b240c0915dce@mail.gmail.com>
To: Luca Passani <passani@eunet.no>
Cc: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
> "tom: Agree, this is saying IE Mobile shouldn't transform, but not sure that
> this could be extended to other browsers not transforming."
> But it certainly can be extended to transcoders to let them know they should
> not transcode.

There's an explanation of what this tag is for here:

http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx

It's a hint to IE to turn off layout optimisations for mobile devices.
I don't think it follows that content designed specifically for mobile
IE can automatically be considered ready for consumption on *all*
other mobile devices. If I access a site designed for mobile IE using
a Series 40 browser, it may be helpful to me for transformation to
take place (subject to the no-transform being respected and headers
only being altered if the user has specifically asked for them to be,
etc etc).

IMHO it's also a poor heuristic for determining mobile-readiness,
given that it's proprietary to a single vendor, and other more
prevalent mechanisms exist.

Tom

 Of course, I am no longer expecting you to acknowledge
> self-evidence, Tom. Do you still go around claiming that you represent
> developers of some sort?
>
> "<SeanP> I agree that we should avoid vendor markup"
>
> of course. Sean, I deeply admire your perseverance.
>
> "<jo> PORPOSED RESOLUTION: Adopt the MS specific <meta
> name="MobileOptimized" content="NNN"> as mandatory evidence of mobile
> content
> <jo> -1"
>
> So much for .Mobi standing by the side of developers, Jo.
>
> Luca
>
> Francois Daoust wrote:
>>
>> Hi,
>>
>> The minutes of today's call are available at:
>>  http://www.w3.org/2009/05/12-bpwg-minutes.html
>> ... and copied as text below.
>>
>> Resolutions taken during the call:
>> - Add an erratum to mobileOK Basic Tests, at the right time, to point to
>> the edited version of XHTML Basic 1.1 including the lang attribute
>> - on MWABP, remove second para of 3.2.1.2 and make no reference to
>> efficiency
>>
>> Francois.
>>
>>
>> -----
>> 12 May 2009
>>
>>   [2]Agenda
>>
>>      [2] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0012.html
>>
>>   See also: [3]IRC log
>>
>>      [3] http://www.w3.org/2009/05/12-bpwg-irc
>>
>> Attendees
>>
>>   Present
>>          tomhume, jo, Francois, rob, EdC, adam, BruceL, SeanP, yeliz
>>
>>   Regrets
>>          jeffs, kai, abel, miguel, nacho
>>
>>   Chair
>>          jo
>>
>>   Scribe
>>          Tom
>>
>> Contents
>>
>>     * [4]Topics
>>         1. [5]FYI - lang attribute back in XHTML Basic 1.1
>>         2. [6]MWABP - new draft out. Feedback needed. Next steps?
>>         3. [7]Mobile/Accessibility document - EOWG decision?
>>         4. [8]Addendum to BP - next editorial session?
>>         5. [9]CT - Abstract
>>         6. [10]CT - Heuristics - mobileOptimized
>>         7. [11]CT - Heuristics - rel="stylesheet"
>>         8. [12]AOB
>>     * [13]Summary of Action Items
>>     _________________________________________________________
>>
>> FYI - lang attribute back in XHTML Basic 1.1
>>
>>   francois: Not much to say on this, except we were talking about this
>>   a few months ago and the XHTMLWG integrated the lang attribute into
>>   XHTML Basic 1.1. The second edition is a "proposed edit
>>   recommendation edition", close to replacing the first edition. When
>>   it's done we can update the DTD in the mobileOK checker to have the
>>   LANG attribute back.
>>   ... This is good news in that we're consistent with the I18N group.
>>
>>   jo: is there a DTD we could use if we want to?
>>
>>   <francois> [14]XHTML Basic 1.1 PER
>>
>>     [14] http://www.w3.org/TR/2009/PER-xhtml-basic-20090507/
>>
>>   francois: there's a schema for those who prefer it.
>>
>>   <francois> [15]DTD in the spec
>>
>>     [15] http://www.w3.org/TR/2009/PER-xhtml-basic-20090507/#a_dtd
>>
>>   francois: this section contains links to the actual files - the
>>   version associated with the document and that evolving over time.
>>
>>   jo: when should we edit the checker?
>>
>>   francois: wait for the document to become a recommendation, and then
>>   update the checker
>>
>>   jo: do we refer to a specific version in the checker?
>>
>>   francois: we're not talking about editions in the document
>>
>>   jo: we don't say anything specific at all, if we're talking about
>>   mobileOK basic
>>
>>   francois: all we have is a link to XHTML Basic 1.1, the dated
>>   version of the first edition. This will link to the new edition.
>>   ... mobileOK basic targets the first edition. We don't say anything
>>   specific about DTDs, and I don't think we need to do anything to
>>   clarify this. We could an erratum to the spec if we need to, to
>>   explain what we mean by the XHTML Basic 1.1 DTD... that it follows
>>   the evolution of XHTML Basic 1.1 recommendation (or not).
>>
>>   jo: but it's not an erratum, it's a clarification...
>>
>>   francois: if moving to the new DTD is a normative change (I think
>>   it's a correction of something wrong), we can't just produce an
>>   erratum. If we feel it's a useful clarification we can add an
>>   erratum - that's the only way to add such comments.
>>   ... let's wait for XHTML Basic to become a recommendation.
>>
>>   <jo> PROPOSED RESOLUTION: Add an erratum to mobileOK Basic Tests, at
>>   the right time, to point to the edited version of XHTML Basic 1.1
>>   including the lang attribute
>>
>>   <brucel> agree
>>
>>   <rob> +1
>>
>>   <francois> +1
>>
>>   RESOLUTION: Add an erratum to mobileOK Basic Tests, at the right
>>   time, to point to the edited version of XHTML Basic 1.1 including
>>   the lang attribute
>>
>>   <EdC> +1
>>
>>   jo: francois, can you enact this pls?
>>
>>   <jo> ACTION: daoust to enact the resolution on XHTML Basic 1.1
>>   revision - when it reaches rec [recorded in
>>   [16]http://www.w3.org/2009/05/12-bpwg-minutes.html#action01]
>>
>>   <trackbot> Created ACTION-959 - Enact the resolution on XHTML Basic
>>   1.1 revision - when it reaches rec [on François Daoust - due
>>   2009-05-19].
>>
>>   <yeliz> +1
>>
>> MWABP - new draft out. Feedback needed. Next steps?
>>
>>   <francois> [17]new draft of MWABP
>>
>>     [17] http://www.w3.org/TR/2009/WD-mwabp-20090507/
>>
>>   jo: we've had no feedback on this document as yet.
>>
>>   adam: I've had some feedback on appcache, an HTML5 feature for
>>   caching web apps locally. It'd be good to have a BP on this subject
>>   and discuss what form this should take. It's very HTML5-specific,
>>   that's all the feedback I've had so far.
>>
>>   <EdC> What about the pending feedback from Francois and myself?
>>
>>   jo: How do you tell that feature is present?
>>
>>   adam: It's supported based on the target platform. Good question.
>>
>>   jo: do we want to discuss the merits of the proposal on this call,
>>   or shall we gather some of these to discuss in a more consolidated
>>   way once we've had feedback? The latter, I suggest
>>
>>   adam: agree
>>
>>   <jo> ISSUE: Should we have a BP on appcache?
>>
>>   <trackbot> Created ISSUE-297 - Should we have a BP on appcache? ;
>>   please complete additional details at
>>   [18]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/297/edit .
>>
>>     [18] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/297/edit
>>
>>   adam: re pending feedback from eduardo... the outstanding issue is
>>   with 3.6.1 and 3.6.2. Agree with your comments, as they're
>>   formulated right now they're a bit mickey mouse and don't reflect
>>   reality. Not sure how to make them better - best solution might be
>>   to make the language more woolly, talk about preferring server-side
>>   XXX. Or if you have specific things you'd like to see in there, feel
>>   free to propose them.
>>
>>   edc: I suggest you write a proposal and I'll comment on it again.
>>   ... The other issue is on sprites.
>>
>>   <francois> [19]3.4.6 CSS Sprites
>>
>>     [19] http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e8981
>>
>>   <jo> ACTION: adam to write a proposal in answer to EdC's comments on
>>   3.6.1 and 3.6.2 [recorded in
>>   [20]http://www.w3.org/2009/05/12-bpwg-minutes.html#action02]
>>
>>   <trackbot> Created ACTION-960 - Write a proposal in answer to EdC's
>>   comments on 3.6.1 and 3.6.2 [on Adam Connors - due 2009-05-19].
>>
>>   adam: barring opinions from others, I don't have any more I can
>>   extract through inspection. 3.4.6 and 3.4.7 are the sections; the
>>   issue is technical and advanced, they're dependent on device support
>>   - we have proposed icons to represent the fact that you need certain
>>   features in the browser for them to make sense as recommendations.
>>   There's a general issue of whether they make sense as
>>   recommendations, or if they're "advanced tweaks"
>>
>>   edc: I'm reminded of multipart-mixed. if its supported (blackberry
>>   and openwave browsers should be ok, safari has lousy support for
>>   it), then it solves all your problems with icons and provides
>>   greater benefits. I wonder what kind of best practice we want to put
>>   into this document.
>>
>>   adam: can someone take an action to investigate multipart-mixed?
>>
>>   <jo> ACTION: Tom to investiagate multipart-mixed in the context of
>>   3.4.6 and 3.4.7 of MWABP [recorded in
>>   [21]http://www.w3.org/2009/05/12-bpwg-minutes.html#action03]
>>
>>   <trackbot> Created ACTION-961 - Investiagate multipart-mixed in the
>>   context of 3.4.6 and 3.4.7 of MWABP [on Tom Hume - due 2009-05-19].
>>
>>   francois: I sent a comment about the security stuff (2.1 - do not
>>   execute untrusted Javascript). Final paragraph needs rewriting.
>>
>>   <francois> [22]3.2.1 JSON
>>
>>     [22] http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e542
>>
>>   francois: again, it's how to find a balance between best practice
>>   and what's acceptable. it makes sense in 99% of cases, there's 1%
>>   where security can be impacted.
>>   ... so maybe it's not a good idea there.
>>
>>   adam: one option would be to remove that paragraph. Or we could
>>   reword this paragraph to ensure that correct escaping is used with
>>   eval(), and that this might even then not be secure.
>>
>>   francois: it's about not having access to sensitive data when you do
>>   it.
>>
>>   adam: I'll have a crack at rewording and send to the list.
>>
>>   jo: wouldn't it be better for the sake of simplicity to remove the
>>   paragraph?
>>
>>   francois: I'd prefer it removed
>>
>>   <jo> PROPOSED RESOLUTION: Remove second para of 3.2.1.2 and make no
>>   reference to efficiency
>>
>>   +1
>>
>>   <rob> +1
>>
>>   <yeliz> +1
>>
>>   RESOLUTION: Remove second para of 3.2.1.2 and make no reference to
>>   efficiency
>>
>>   <francois> +1
>>
>>   RESOLUTION: Remove second para of 3.2.1.2 and make no reference to
>>   efficiency
>>
>>   <adam> +1
>>
>>   <EdC> +1
>>
>>   francois: one thing I can do is to write a post on the BPWG blog to
>>   trigger reactions.
>>
>>   <jo> ACTION: Francois to reach out for comments on MWABP via the
>>   BPBlog [recorded in
>>   [23]http://www.w3.org/2009/05/12-bpwg-minutes.html#action04]
>>
>>   <trackbot> Created ACTION-962 - Reach out for comments on MWABP via
>>   the BPBlog [on François Daoust - due 2009-05-19].
>>
>>   francois: could you reach your respective developer communities too?
>>   I suspect we won't get much feedback, it's a working draft and not a
>>   last call (last calls tend to trigger reactions)
>>
>>   jo: any idea of groups we should particularly outreach to?
>>
>>   <EdC> Suggestion: if anybody blogs, try to participate in the
>>   Carnival of the mobilists: [24]http://mobili.st.
>>
>>     [24] http://mobili.st/
>>
>>   adam: feels like a dearth of feedback. Been pushing hard at work for
>>   this.
>>   ... I'm inclined to sit on it for a week or two whilst I make
>>   outstanding changes and wait for feedback internally. That draft can
>>   be our LC candidate.
>>
>>   jo: so LC will be end this month/early june
>>
>> Mobile/Accessibility document - EOWG decision?
>>
>>   yeliz: as far as I know there hasn't been any agreement to proceed
>>   with the publication of the draft.
>>
>>   jo: any action required from our side?
>>
>>   francois: i've not checked emails of the education/outreach group.
>>   We took a resolution 2 weeks ago to publish the draft as soon as
>>   they're ok with it.
>>
>>   jo: so we've prior approved it... we can go ahead when ready.
>>
>> Addendum to BP - next editorial session?
>>
>>   jo: I'm the blocker here, haven't added some further comments. We'll
>>   need an editorial session following that.
>>   ... it'll be a couple of weeks before I get a chance to do more on
>>   this.
>>
>> CT - Abstract
>>
>>   <adam> +1
>>
>>   <brucel> bruce test
>>
>>   jo: on action 929, appreciate your input here Eduardo - I do have
>>   some comments. Apologies for not replying.
>>   ... would rather make them on-list than now.
>>
>>   <EdC> Let us defer then.
>>
>>   jo: so let's defer that discussion. Apologies for not making
>>   progress, it'll be another couple of weeks before I can address it.
>>   ... anything else on CT from anyone?
>>
>> CT - Heuristics - mobileOptimized
>>
>>   jo: the problem with recommending specific vendor things is obvious,
>>   but if they're prevalent in the marketplace it's equally problematic
>>   not to mention them.
>>
>>   ed: MS has faced the problem of having devices that are more capable
>>   and less capable and having several ways of viewing pages - fit to
>>   screen, view as is, try to do something clever, etc. - and they
>>   realised there was a need to let developers state explicitly that
>>   the content was optimised, there's no need to try and do something
>>   clever with it, it will display OK on mobile, etc.... so ignore the
>>   default browser settings and do what the content provider intended.
>>   ... so it's been there for some time. It's documented in the MS
>>   mobile windows site. Its importance is that it's a rare indication
>>   that HTML content has been developed for mobile.
>>
>>   <brucel> does the metatag say *which* mobile browser/phone its
>>   already optimised for?
>>
>>   ed: usually all the rules we've examined have had to do with content
>>   types, markers, which were almost-exclusively used by mobile devices
>>   and not by PC browsers... and this is the only indication in HTML
>>   content that is unambiguously indicative that this is HTML content
>>   optimised for smartphones.
>>   ... It is attached to windows mobile devices, whatever their
>>   market-share is at present.
>>
>>   bruce: does it say which browser/phone the content is optimised for?
>>   Or that I as a developer am certain this is lean and mean? I'm not
>>   sure what the tag means.
>>
>>   ed: it's an indication that is meant for internet explorer
>>
>>   <francois> [25]Layout meta tag in MSDN
>>
>>     [25] http://msdn.microsoft.com/en-us/library/ms890014.aspx
>>
>>   <francois> [[ Web developers use the MOBILEOPTIMIZED meta tag to
>>   control the Internet Explorer Mobile layout ]]
>>
>>   ed: it'll be ignored by any other browser.
>>
>>   bruce: so are we saying if this tag exists it must be obeyed and no
>>   transformation must be done by any browser... or not by IE?
>>
>>   jo: it is conclusive evidence that the site has been created for
>>   mobile
>>   ... the question it raises to me is that if we see evidence in the
>>   markup that specific devices are being targeted... is it equally
>>   conclusive evidence that its' ready for the device we're targeting
>>   to?
>>   ... if you want to show evidence your markup is targeting mobile
>>   there are lots of other ways of doing it.
>>
>>   bruce: i agree with you that we shouldn't crown any vendor-specific
>>   marker.
>>
>>   <yeliz> I agree with Bruce as well
>>
>>   ed: there are lots of other ways of doing it. i'd like to know what
>>   they are, given that we're restricting them.
>>   ... this is the only markup I know that will work for HTML (as
>>   opposed to XHTML, WML, etc)
>>
>>   jo: you could use rel="handheld" with a self-referential link
>>   ... my preference is that vendor-specific things irrespective of
>>   whether the device belongs to that vendor is a dangerous path.
>>
>>   <Zakim> tomhume, you wanted to wonder if it's evidence the site is
>>   made-for-mobile or made-for-mobile-IE?
>>
>>   <brucel> I'm not against vendor-specific stuff per se, and IE can
>>   obey its own metatags, but noone else should be bound by them
>>
>>   tom: Agree, this is saying IE Mobile shouldn't transform, but not
>>   sure that this could be extended to other browsers not transforming.
>>
>>   <SeanP> I agree that we should avoid vendor markup
>>
>>   <jo> PORPOSED RESOLUTION: Adopt the MS specific <meta
>>   name="MobileOptimized" content="NNN"> as mandatory evidence of
>>   mobile content
>>
>>   <jo> -1
>>
>>   <rob> 0
>>
>>   -1
>>
>>   <EdC> 0
>>
>>   <francois> -1
>>
>>   <SeanP> -1
>>
>>   <yeliz> -1
>>
>>   <brucel> -`1
>>
>> CT - Heuristics - rel="stylesheet"
>>
>>   <francois> [26]EdC's email
>>
>>     [26] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html
>>
>>   ed: this relates to XHTML stylesheets. You can, with some
>>   transcoders, mark stylesheets and control how much is filtered out
>>   by transcoders. The proposal is "if you see the XHTML stylesheet
>>   which is marked as mobile-ready, in principle they shouldn't be
>>   taken out". External stylesheets marked as "all" mean "good for
>>   every device". Here the point is that there are some browsers (newer
>>   ones especially) that will not consider ALT stylesheets but take
>>   desktop and ALL
>>   ... since ALL covers both categories (mobile and full web), the
>>   second part of the proposal is to say "ALL means ALL" and it
>>   shouldn't be touched.
>>
>>   <Zakim> francois, you wanted to wonder about what should not be
>>   touched
>>
>>   francois: what should not be touched? The XHTML content, the HTML,
>>   the CSS?
>>
>>   ed: the CSS
>>
>>   francois: it only makes sense if you don't touch the XHTML. In many
>>   cases you could make changes in the HTML, then CSS changes are
>>   required... as you change the structure of the HTML page some
>>   directives are no longer valid and don't make sense. If you change
>>   the HTML you may need to change the CSS - not that CT proxies
>>   necessarily do this properly...
>>   ... so we can't prevent it in the guidelines.
>>
>>   jo: this sounds like the discussion on the transformability or
>>   otherwise of images. is there a parallel worth considering?
>>
>>   ed: you might have XHTML which does links without native for
>>   handheld/desktop stylesheets. You might change the HTML but not
>>   stylesheets.
>>
>>   <SeanP> Francois is correct; if you change the markup, you probably
>>   will need to change the CSS
>>
>>   jo: sean/rob? any comment?
>>
>>   sean: agree with francois. If the markup is changed, good chance you
>>   need to change the CSS too.
>>
>>   ed: if you don't change the XHTML, does it make sense to change the
>>   CSS? No.
>>
>>   jo: this is even more similar to "if there's a no-transform on the
>>   HTML, does this have implications to included parts". We decided
>>   not, on images. Does the same argument apply here?
>>
>>   ed: The same would apply but here we're explicitly saying "yes, if
>>   it's for a mobile device".
>>
>>   sean: if you have a no-transform or some other content type, it
>>   should apply to the CSS.
>>
>>   jo: a derived no-transform rather than an explicit one.
>>
>>   <Zakim> rob, you wanted to say seems sensible to either transform
>>   both HTML and CSS together or change neither
>>
>>   <brucel> I need more time to think thru after the explanations ...
>>
>>   rob: agree with ed and sean. typically you'd change both HTML and
>>   CSS or neither. can't see any reason to just change CSS.
>>
>>   <jo> PROPSOED RESOLUTION: If the HTML is being treated as "no
>>   transform" then external stylesheets retrieves as a consequence of
>>   retrieving the HTML should be treated the same
>>
>>   <jo> PROPOSED RESOLUTION: If the HTML is being treated transparently
>>   then external stylesheets retrieved as a consequence of retrieving
>>   the HTML should be treated the same
>>
>>   <Zakim> tomhume, you wanted to wonder if we argued against "derived
>>   transformation" as it imposed a page model on HTTP where none
>>   existed before.
>>
>>   ed: at the time, we were imposing that model on a specific feature
>>   (the no-transform directive). Here we're not saying it's linked to
>>   that...
>>
>>   francois: i'm confused... I can see examples where we might want to
>>   change CSS (e.g. absolute positions of resources).
>>   ... we're talking about external stylesheets in general, not
>>   handheld ones.
>>
>>   jo: what about recursively referenced stylesheets?
>>
>>   ed: ALL or "handheld" would be the one to work on
>>
>>   jo: how far should this go?
>>
>>   ed: as far as the recursion goes.
>>
>>   jo: what about stylesheets that are referenced from stylesheets that
>>   are themselves references as "all" or "handheld" - do they inherit
>>   properties?
>>
>>   ed: logically, yes.
>>
>>   jo: I'd like us not to take a resolution on this without considering
>>   our previous decision. There are caching implications here too, and
>>   indefinite numbers of recursively referenced stylesheets.
>>
>>   +1
>>
>>   <francois> +1
>>
>>   <brucel> +1
>>
>>   <yeliz> +1
>>
>>   <SeanP> It does sound like we need to think about this a bit.
>>
>>   <SeanP> I think that is correct.
>>
>>   francois: another question on handheld and all. One part is about
>>   having the "link alternate"... we agreed not to have "all" mentioned
>>   in the list of mandatory heuristics (for reasons I can't remember).
>>   ... The same reasons should apply here as well.
>>   ... we should dig into the archives.
>>
>>   <EdC> Is there also a recursion problem with alternate links?
>>
>>   <jo> ISSUE: with reference to Eduardo's point about linked
>>   stylesheets,
>>   [27]http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.htm
>>   l, we need to review in the light of an earlier decision on images
>>   and possibly aslo in light of a recursion problem with link
>>   rel="alternate" (per discussion of meeting on 12th May)
>>
>>     [27] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html
>>
>>   <trackbot> Created ISSUE-298 - With reference to Eduardo's point
>>   about linked stylesheets,
>>   [28]http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.htm
>>   l, we need to review in the light of an earlier decision on images
>>   and possibly aslo in light of a recursion problem with link
>>   rel="alternate" (per discussion of meeting on 12th May) ; please
>>   complete additional details at
>>   [29]http://www.w3.org/2005/MWI/BPWG/Group/track/issues/298/edit .
>>
>>     [28] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0011.html
>>     [29] http://www.w3.org/2005/MWI/BPWG/Group/track/issues/298/edit
>>
>> AOB
>>
>>   jo: anything?
>>
>>   <brucel> nah
>>
>>   <yeliz> no from me as well
>>
>>   <brucel> Bye, kisses all
>>
>>   <jo> [bye]
>>
>>   <EdC> bye
>>
>> Summary of Action Items
>>
>>   [NEW] ACTION: adam to write a proposal in answer to EdC's comments
>>   on 3.6.1 and 3.6.2 [recorded in
>>   [30]http://www.w3.org/2009/05/12-bpwg-minutes.html#action02]
>>   [NEW] ACTION: daoust to enact the resolution on XHTML Basic 1.1
>>   revision - when it reaches rec [recorded in
>>   [31]http://www.w3.org/2009/05/12-bpwg-minutes.html#action01]
>>   [NEW] ACTION: Francois to reach out for comments on MWABP via the
>>   BPBlog [recorded in
>>   [32]http://www.w3.org/2009/05/12-bpwg-minutes.html#action04]
>>   [NEW] ACTION: Tom to investiagate multipart-mixed in the context of
>>   3.4.6 and 3.4.7 of MWABP [recorded in
>>   [33]http://www.w3.org/2009/05/12-bpwg-minutes.html#action03]
>>
>>   [End of minutes]
>>
>>
>
>
>



-- 
Future Platforms: hungry and foolish since 2000
work: Tom.Hume@futureplatforms.com play: tomhume.org
Received on Tuesday, 12 May 2009 22:35:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC