W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[widgets] Draft Minutes from 9 June 2009 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 12 Jun 2009 06:42:39 -0400
Message-Id: <46A4E8CC-6520-477E-9E64-4FF519A03E66@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the June 9 Widgets f2f are available at the  
following and copied below:


WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before 18 June 2009 (the next  
Widgets voice conference); otherwise these minutes will be considered  

-Regards, Art Barstow


       [1] http://www.w3.org/

                           Widgets F2F Meeting
                               09 Jun 2009


       [2] http://www.w3.org/2008/webapps/wiki/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2009/06/09-wam-irc


           Benoit, Mike, Josh, Jere, Art, Robin, Marcos, AndyB, DanA,
           David, Laura, Marcin, Bryan, Magnus, Richard, Frederick,
           Thomas, SteveL


           ArtB, Art, Bryan, Art, Mike, Dan


      * [4]Topics
          1. [5]Introductions
          2. [6]Confidentiality of Minutes
          3. [7]Agenda Tweaking
          4. [8]Packaging and Config spec
          5. [9]Localization
          6. [10]Localisation
          7. [11]Access Requests Policy
          8. [12]URI Scheme
          9. [13]P+C
         10. [14]Updates
         11. [15]Discussing Brian's input
      * [16]Summary of Action Items


    AB: Arve had a last minute cancelation and will not attend
    ... registered but not here yet: Paddy, Richard Tibbett, Jonathon,
    Nick and Ivan

Confidentiality of Minutes

    AB: all of the minutes will be Public
    ... any questions about that?

    [ None ]

Agenda Tweaking

    AB: Agenda:
    ... we will start with P+C this morning
    ... talk about high priority issues
    ... from 13:00-15:00 today we will talk about Security Model
    vis-a-vis <access> and the WARP document

      [17] http://www.w3.org/2008/webapps/wiki/ 

Packaging and Config spec

    AB: spec: [18]http://dev.w3.org/2006/waf/widgets/
    ... other than feature and L10N are there other hot topics?

      [18] http://dev.w3.org/2006/waf/widgets/

    MC: no not really

    AB: Henri's
    ... comment about clarifying purpose of feature
    ... I think the way we have documented feature in P+C is OK
    ... but there are questions about what a UA will do with the data
    ... what is our plan to specify the behavior?

      [19] http://lists.w3.org/Archives/Public/public-webapps/ 

    <scribe> Scribe: Art, Mike

    <MikeSmith> Scribenick: MikeSmith

    ArtB: what work remains to be done for <feature>?

    Marcos: I don't think anything more needs to be done.. it's

    ArtB: Anybody disagree with that?

    Marcos: Biggest impact is on BONDI, so it matters most if it is OK
    as-is for them.
    ... I think it meets the BONDI use cases.

    Robin: If OMTP is OK with it, I'm OK with it.
    ... I'm happier with use cases that don't require it, because that's
    more Web-like.

    David: In the absence of a more proper security model, we still
    support this.
    ... We are happy for [the editors] to take the lead on this.

    Marcin: We just want it to be stable.

    ArtB: Is OMTP going to extend it after?

    Bryan: We may add some semantics, but we are not planning to add
    additional attributes.

    David: If we have a policy mechanism -- some way of regulating
    access for the user -- then this element is actually redundant.

    Marcos: So it really is more of a stop-gap for now

    ArtB: Anybody else have anything to add on this topic?

    PROPOSED RESOLUTION: The group agrees that the <feature> element as
    defined in the LC WD is complete.

    ArtB: Any objections?


    RESOLUTION: The group agrees that the <feature> element as defined
    in the LC WD is complete.

    Marcos: [discussing issue of case sensitivity in localization

    [discussion about mailing-list discussions from last couple days]

    Marcin: [talking specifically about recent BONDI decisions around
    requestFeature() and widgets vs. Web pages]

    Marcos: as far as requestFeature(), as this point, it does not exist
    in the Widgets specs.

    David: Yeah, we are still just discussing it within OMTP.

    Marcin: [explaining background on submission of BONDI specs for
    review within W3C]

    Bryan: One question is: Do we have the ability to author [a
    document] as both a Web page and a Widget.
    ... Another question is around dynamically loading.

    Marcos: I think the DAP WG will be the one that needs to answer

    timeless_mbp: because of localization and path constraints,
    currently you won't be able to [drop a widget into a page and have
    it work]

    Marcin: In theory, for this case, the widget UA should be behaving
    conceptually in the same way as an HTTP server.

    ArtB: What I see is that David announced "we are now done, please

    David: So if it's the view of the WebApps WG that getFeature() is
    more correctly specified within the DAP WG, then we would follow
    your lead on that.

    Marcos: The problem is that it currently seems to make assumptions
    about a particular architecture.

    Robin: Yes, the feedback you are likely to get from browser vendors
    is that as currently specified, it does not match with browser
    architecture, and there are other ways to solve the problem.

    Marcin: The whole BONDI initiative came about because of need for a
    "fast standard".. but BONDI operates under many of the same
    principles as the W3C.
    ... The expectation is that everything that has been produced by
    BONDI will be reviewed within W3C... but none of what BONDI has
    produced thus far is considered a "must".

    David: so to step back, we don't have DAP yet, so we need a stop-gap
    in the meantime to address the issue


    <scribe> Scribenick: Bryan


    <ArtB> Jere's comments:

      [20] http://lists.w3.org/Archives/Public/public-webapps/ 

    <ArtB> P+C ED: [21]http://dev.w3.org/2006/waf/widgets/

      [21] http://dev.w3.org/2006/waf/widgets/

    Jere: comments were mostly editorial

    <ArtB> Macros' response to Jere:

      [22] http://lists.w3.org/Archives/Public/public-webapps/ 

    Marcos: the main issue was case sensitivity in localisation
    ... effectively what we have for localisation is a language list and
    a list of folders. the algorithm is to do a string match, case
    ... the solution is to match everything in the local part of a path

    Josh: forcing failure for anything other than lowercase is another
    ... it is easy to write an algorithm than discards anything that
    does not match with lower case

    Marcos: we need to ensure we don't violate ISO specs re case

    Robin: we don't need to follow the ISO specs

    Josh: the widgets spec is not defining a language code thus we don't
    have to follow rules for languages

    <Marcos> RESOLUTION: in the spec, we will mandate that language tags
    for locale folders be in lowercase form (relevant to authors). Only
    locale folders in lowercase form will be matched by the widget user

    Jere: is it possible to have upper-case folders present anyway, and
    the sensisble thing is to fold it to lower case and continue

    Robin: the sensible thing to do is to discard folders that are

    Jere: compromise, allow any case as long as it's unique and then
    treat it as lower case

    Robin: in a case insensistive file system, how to handle if the
    language tag folders are not unique - the easiest is just to kill

    Bryan: what is the downside of ensuring uniqueness and case folding?

    Josh: it can cause confusion as the author was expecting one
    behavior and gets another

    <timeless_mbp> DRAFT RESOLUTION: any folder as a direct child of the
    locales folder whose name is not entirely in lowercase will not be
    reachable by any means.

    David: is there any existing requirement mandating lowercase in the

    Josh: there is precedent in other specs to require case sensitive

    No objections.

    RESOLUTION: any folder as a direct child of the locales folder whose
    name is not entirely in lowercase will not be reachable by any

    Art: are there still some comments on localisation outstanding?

    Jere: some editorial comments, the email exchange is ongoing

    Marcos: it was proposed to reshuffle the content which is now done,
    e.g. the localisation is now in one area. Need to do a read-thru to
    ensure good flow
    ... there's nothing else that is editorial - the question on
    xml:lang needs to be resolved

    Josh: in 5.3 the locale/folder needs to not reference the folder
    name - it needs to be called "locale folder" or something that makes
    it clear what we are referring to

    <timeless_mbp> not locale folder since that's taken

    <timeless_mbp> but locale-folder-name which might reference BCP47
    with a prose restriction to lowercase, or a copy of BCP47 with the
    BNF restricted to lowercase

    Marcos: to fix this, we need to change elements of the ABNF if we
    were to take the language tag from bcp47

    Robin: it is better to restrict it in prose rather than ABNF

    <timeless_mbp> ok :)

    Jere: the issue raised re xml:lang values being unique, does this
    come from I18N best practices?

    Michael: from HTML5, for authoring we have encouraged people to move
    away from xml:lang

    Robin: that's because HTML4 had a lang tag and there is thus
    duplication. in our case we are starting from scratch
    ... for widgets, we define the processing model and it will clarify
    how to handle the set of xml:lang entries

    Marcos: the entries are specified to be in document order

    Marcin: does this work related to ITS?

    Marcos: it relates since the ITS affects to to handle character

    Jere: the issue is resolved since the description will define the

    Marcos: in the 1st example of step 5, we need to make the language
    sequence consistent, and to ensure what is being ilustrated is
    ... the use case is the user has entered the language preferences,
    and the widget user agent ensures the list of languages is per the
    spec, and to avoid confusion we need to be clear on how it does that

    Benoit: is there a point inthe processing model, how specific the
    selected language needs to be

    Marcos: there are those who want a specific dialect over the generic
    or another dialect

    Josh: there are those that would prefer english for example to an
    unknown dialect of their language

    Marcos: the question is how to eliminate repetitions/ambiguity in
    the selected list

    Josh: the processing should enable e.g. avoidance of random untagged
    english if another language is preferable

    Art: are there any objections to the processing model presented on
    the screen?

    <Marcos> Draft Resolution: treat language tags in the order they
    appear in the UA Locale list, instead of treating them as
    recommended by BCP47.

    <Marcos> "en-us,en-au,fr,en"

    <Marcos> Would become:

    <Marcos> "en-us,en-au,fr,en"

    <Marcos> "en-us,en-au,fr"

    <Marcos> Would become:

    <Marcos> "en-us,en-au,en,fr"

    Josh: the example does not yet quite meet the draft resolution

    Art: it's a question for Josh and Marcos to figure out how to word
    in the spec

    Resolution: treat language tags in the order they appear in the UA
    Locale list, instead of treating them as recommended by BCP47.

    Jere: an outstanding issue is the runtime resolution of the
    resources, we can discuss that later

    <ArtB> Scribe+ DanA

    <darobin> do you see me?

    <tlr> darobin, if you could dial into the bridge?

    <DKA> Scribe: Dan

    <DKA> ScribeNick: DKA

    [back from lunch]

Access Requests Policy

    Art: I'm projecting the June 5 version of the WARP document.
    ... We want to use this time to go through this document and solicit
    comments. One question I'd like to pose is - is there consensus to
    publish the document as FPWD?

    <ArtB> [23]http://dev.w3.org/2006/waf/widgets-access/

      [23] http://dev.w3.org/2006/waf/widgets-access/

    Art: over to Robin for a quick walk-through

    Robin: To give some background - this spec defines the access
    element which was previously in PnC and got dropped out to a
    separate spec rather than delay PnC.
    ... It follows typical structure.
    ... It has a simple model whereby the access grants access within
    the widget execution scope to certain network resources but anything
    that is outside the widget executtion scope
    ... does not have the same levels of access.
    ... The advantage: it maintains protection to sensitive APIs because
    you can't communicate across iframe boundaries. etc...

    Bryan: clarify?

    Robin: if you have a widget with access to the address book (e.g.)
    and in a separate context you have an access element that grants it
    to load something from a foreign host then this context will not
    have access to the address book.

    <Zakim> Thomas, you wanted to note that it *can* communicate, but
    the widget is able to control that access

    Thomas: to clarify - a very limited amount of communication is
    possible using APIs like post message... you do have cross-origin
    communication within a browser. But this is tightly controlled by
    the widget. The important point is that the widget cannot script the
    iframe and the iframe cannot script the widget.
    ... This gives us a very well-defined interface and puts relatively
    strict limits - doesn't give access from the web to "risky" APIs

    Robin: there's no information leakage unless you've trusted an evil

    Josh: With an iframe, to a normal user, you can load a javascript
    URL that executes arbitrary code in the context of that web page....
    Assuming the widget will not be allowed to do that.
    ... That code executes in the context of the iframe. It doesn't have
    access to the widget but it has total access to the iframe.

    Robin: Yes.

    Josh: So it's not a very tall wall in that direction.

    <Zakim> timeless_mbp, you wanted to verify that the widget can't
    load javascript:scriptWidget() in the iframe

    Robin: The rest of the spec is the syntax and the processing model.
    ... There have been two messages so far with editorial comments
    which I'll apply before we publish.

    [discussion of the comments from Thomas from today]

    <ArtB> TLR's comments today:

      [24] http://lists.w3.org/Archives/Public/public-webapps/ 

    Thomas: Point 3 in my notes - I continue to not be convinced that
    it's a good idea to build a new model within the widget that
    contains inline content.
    ... other points raised are editorial in nature.
    ... [discusses his additional comments]
    ... To give an example, the document talks about parsing in document
    order but this doesn't have anything to do with this specification.
    ... [suggests compressing the parsing instructions]

    Robin: WRT point 2. I was thinking that it shouldn't say anything
    about HTML5 security policy but should just say that it uses the
    security policy "of the host language being used" which removes the
    dependency on HTML5.

    Josh: there are 2 parts that reference HTML5.

    Art: Any objections to that proposal?

    Josh: The other HTML5 reference needs to point to some other thing.

    Bryan: [clarify web application scope?]

    <ArtB> [ Discuss "The widget execution scope is the scope (or set of
    scopes, seen as a single one for simplicity's sake) being the
    execution context for code running from documents that are part of
    the widget package. Note that a script loaded from an external URI
    into a document that is part of the widget is running in the widget
    execution scope. " ]

    Bryan: If I load a script off of the Web and I run that within a
    container that is part of the html page that the widget as defined,
    is that web scope or widget scope?

    Robin: If the access has been granted by the access element then it
    is running in the widget context.

    Bryan: if I load further scripts then those have the same

    Robin: Yes.

    Bryan: Where do we transition to the Web scope?

    Robin: If you have another document - like an iframe - which has an
    origin that is not inside the widget.

    <timeless_mbp> for my reference, CORS is

      [25] http://www.w3.org/TR/cors/

    Robin: The case of bringing in script from the web relys on the
    access element having granted that access [in the widget context] so
    subject to the access policy.
    ... A widget can contain multiple documents... All of those
    documents run within the widget scope. If one of those runs a script
    from a URI on the web then that script is running in the widget
    ... We don't want to constrain the security models for others within
    this spec.
    ... We don't want to break the Web.

    Bryan: Suggests inserting a [zzzt zzzt]

    <tlr> [awfully noisy call right now]


      [26] http://lists.w3.org/Archives/Public/public-webapps/ 

    Bryan: Suggests inserting a concrete example in the document to

    Frederic: I support having more details in the examples - e.g. the
    airline flight tracker. If you have a feature that allows access to
    the camera ...

    <timeless_mbp> Zakim: mute [london]

    Frederic: it talks about feature-enabled APIs in section 2. I assume
    feature enabled then that feature applies to anything [in that

    Thomas: Any script that can control the widget execution context
    would have access to that feature.

    Robin: I will put a specific example in to clarify.

    Frederic: This is truly for network access and not for anything else
    (e.g. a URI to a feature).

    Bryan: A local host URI such as a smartcard web server would be


    Robin: Your definition of a network resource is anything with a URI
    that is referenced by DNS or IP.


    <Zakim> timeless_mbp, you wanted to ask if <access
    uri="[27]http://redirect.example.org"> and a widget has <iframe
    would be

      [27] http://redirect.example.org/
      [28] http://redirect.example.org/?http://somethingelse.com

    Robin: If access says it's OK to access foo.com and you load foo.com
    and it redirects to bar.com.

    Josh: [advertisement for CORS

    Thomas: Don't have an easy answer to the redirect question. Not
    clear that CORS is the answer. The fundamental distinction we have
    is ...
    ... just mixing redirects and origin determination could be a huge
    security hole.

    Frederic: We have the asterix which allows access to all assets -
    could this become a problem?

    Robin: this was debated before but not everyone was happy with the
    solutiuon. But if you want to access something like google maps you
    get a zillion subdomains...

    Steve: There's no way to state that intent more explicitly?

    Robin: if you enable foo.com and its subdomains then it could allow
    access to an IP address in your internal network.

    [consensus we need to fix the web or something]

    Robin: a user agent would assign an opaque, unique, global
    identifier to each instance.

    Thomas: I suggest we leave this open because there is a proposal to
    assign the same identifier to different widgets if they have been
    signed with the same cert.

    Robin: We remain silent.

    Josh: What about multiple instances?

    Robin: Currently undefined.

    Thomas: We don't know right now - probably something we should leave
    undefined at this time.
    ... When it comes to local storage they would have to take care of
    not stepping on eachother's toes. That's the one [problem area I see
    with multiple instances]

    Art: where are we wrt FPWD?

    <lewontin> Possible that device access security model might further
    restrict access beyond same-origin.

    <fjh2> I was the speaker asking about making intent more explicit...

    <lewontin> This shouldn't affect anything in this spec explicitly.

    Art: What kind of time-frame are you thinking?

    Robin: I can do it this week.

    Art: I'd like to give Robin the freedom to make those changes.

    PROPOSED RESOLUTION: The WARP document modulo the changes Robin's
    agreed to make is ready for FPWD.

    [no objections]

    RESOLUTION: The WARP document modulo the changes Robin's agreed to
    make is ready for FPWD.

    Robin: Short name?

    Art: My recommendation is widget-access

    [discussion on what to cover next]

URI Scheme

    <ArtB> Spec:

      [29] http://dev.w3.org/cvsweb/2006/waf/widgets-uri/Overview.html


      [30] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/ 

    <darobin> [31]http://dev.w3.org/2006/waf/widgets-uri/

      [31] http://dev.w3.org/2006/waf/widgets-uri/


      [32] http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-uri/ 

    Art: Over to Robin.

    <Marcos> [33]http://dev.w3.org/2006/waf/widgets-uri/

      [33] http://dev.w3.org/2006/waf/widgets-uri/

    Robin: This isn't up to date with the latest edits.
    ... I want to propose that the authority is a string that must be
    ignored in this version. Paves the path forward for use of
    signatures in future versions.

    <Marcos> Scribe+ Marcos

    <Marcos> ScribeNick: Marcos

    RB: with the issues listed at the begining, plus a few other things,
    we have enough to run with for version 1

    <tlr> works for me

    <tlr> certainly ready for FPWD

    JS: what does it mean to ignore the authority?

    RB: [gives background on whiteboard]
    ... we started that the Origin was synthetic opaque with a UUID,
    then ppl complained about the UUID so we got rid of it. So the
    authority part could be used for other things, like crypto.

    JS: the DOM should not reflect that authority?

    RB: in future versions, we might make use of the authority part

    TR: so my understanding is that, when the URI gets dereferenced, the
    authority part gets ignored...
    ... the authority does not carry any semantics right now...
    ... the idea is just to keep it open for now, so we can do more with
    it later

    RB: Agreed

    SL: might need to clarify that in section 4 of the spec

    TR: need clarifications or it's going to be hard to parse

    <tlr> 3986

    RB: it still conforms to the URI specification, and the UUID would
    still be dropped

    <tlr> (thinking about this, I was wrong; ignore)

    <tlr> (about the character repertoire, that is)

    <lewontin> Maybe we want to drop the word "unique" in section 4
    since we left open the possibility that multiple instances or
    multiple widgets might share the same URI

    <tlr> +1 to dropping "unique"

    JS: I need to read the spec, will try to do that now
    ... have editorial comments

    AB: if we look at the issues at the top of the doc. It seems we have
    closed a few of those issues

    RB: a lot of those are editorial
    ... so unicode, UUID are dropped. Can reference a bunch of things
    from P&C. And the thing about dig sig, not sure what I meant.

    JS and RB discuss some minor issues

    AB: It's highly likely we are going to get some feedback once this
    goes out. So, I'm inclined to push of a FPWD ASAP.

    RB: I can have it ready this week

    AB: the question is the, should we agree on a FPWD today?

    RB: I think so

    MC: I agree

    AB: Robin will make the changes, so I propose to the group that we
    get a resolution to publish

    PROPOSED RESOLUTION: The group agrees to publish a FPWD once changes
    agreed on during this discussion have been spec'd.

    RB and BS discuss synthetic origins

    <ArtB> BS: I would like to see a definition of synthetic added

    <ArtB> RB: yes, I will add a definition

    RB: a lot of people were uncomfortable with widget://

    <tlr> tlr; think it's a bad idea to have a URI scheme which you
    can't ever write out in absolute

    <tlr> tlr: think it's fine to have authoring guideline that says
    "relative uri references preferred"

    <tlr> tlr: bu also think it's a bad idea to forbid them in the

    BS: if I want to call a local resource, can I pass it a parameter?

    RB: it should work, the javascript could access the relevant
    document property and access that information
    ... you would not be able to post to a widget URI

    JS: when I talked to TR, we agreed that POST would not work for 1.0,
    but may be something that gets added later

    BS: how does this work with HTTP?

    RB: there is no relationship to HTTP, it's just a URI

    TR: the only thing we define for the URI scheme is how to retrieve
    files form a packaged, but nothing else. WRT queries, they are
    ignored, but is reflected in the DOM... but we don't say that right
    now, but it should say it in the spec

    RB: fragments also
    ... ppl will be surprised if they are not there

    TR: query is part of the resource identification
    ... fragment happens after the uri is dereferenced

    RESOLUTIONS: The group agrees to publish a FPWD once changes agreed
    on during this discussion have been spec'd.

    <ArtB> Larry:

      [34] http://lists.w3.org/Archives/Public/public-webapps/ 

    AB: before we close this topic, I did want to follow up on this
    topic. Larry sent an email about thismessage

    <ArtB> AB: the wiki

      [35] http://www.w3.org/2008/webapps/wiki/WidgetURIScheme

    AB: at some point we were keeping track of all the candidates for
    URI schemes
    ... in the wiki

    RB: on first reading, it seemed very MIME constrained

    JS: yes, I found the same thing.

    JS reads the abstract

    <timeless_mbp> [36]http://www.rfc-editor.org/rfc/rfc2557.txt

      [36] http://www.rfc-editor.org/rfc/rfc2557.txt

    <timeless_mbp> last paragraph, first sentence

    <timeless_mbp> This document a) defines the use of a MIME

    <timeless_mbp> structure

    <timeless_mbp> -- if the abstract is accurate, then the RFC isn't
    portable for us

    RB: I think we need to deconstruct it and see what is good/bad in

    <timeless_mbp> -- if the abstract is not accurate, then the RFC
    isn't worth reading

    <timeless_mbp> oh, *of first page

    <scribe> ACTION: Send Larry a proper response about "thismessage"
    and how it relates to Widget URI scheme
    [37]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in

      [37] http://www.rfc-editor.org/rfc/rfc2557.txt

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

    <scribe> ACTION: Robin to send Larry a proper response about
    "thismessage" and how it relates to Widget URI scheme
    [39]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in

      [39] http://www.rfc-editor.org/rfc/rfc2557.txt

    <trackbot> Created ACTION-353 - Send Larry a proper response about
    "thismessage" and how it relates to Widget URI scheme
    [41]http://www.rfc-editor.org/rfc/rfc2557.txt on Robin Berjon - due

      [41] http://www.rfc-editor.org/rfc/rfc2557.txt

    RB: from what I read it was _very_ MiME related

    BS: what is the context of this discussion?

    JS: the TAG is against creating new URI schemes unless one is REALLY

    AB: the history here is that we decided we needed a new URI scheme
    for widgets, but we need to explore the whole landscape to make sure
    nothing fits.

    RB: I'm happy to discuss this with the TAG
    ... I love the TAG, I'm hoping I will be appointed to it.

    <darobin> MC: I want to chair the AB

    <Bryan> hello

    <darobin> Scribe+ Robin

    <ArtB> ScribeNick: darobin


    AB: Jere, did we finish your comments?

    JK: I think so yes, waiting on an email from MC for formal

    MC: will do that

    JK: do we need that for the DoC? Do I need to say I'm happy?

    MC: yes

    JK: not trying to push MC

    MC: need to make sure I've addressed everything

    AB: from a process & scheduling perspective LC ends on 19/06, so no
    specific rush

    JK: happy to co-ordinate offline

    AB: that's done
    ... anything heard from XML Core?

    MC: no

    <scribe> ACTION: Art to ping XML Core and the XML CG about reviewing
    our PC LC [recorded in

    AB: MWBP was also reviewing

    <scribe> ACTION: Art to follow up with MWBP chairs for LC comments
    [recorded in

    AB: Marcin, you've sent several comments
    ... do you want to discuss them in the group

    MH: I think we're handling it on the mailing list
    ... I'm not sure who else would speak up about versioning and

    AB: I wanted to talk about versioning
    ... what is the consensus about versioning for PC — emails trail off
    but that doesn't mean we have consensus and no issues

    MC: I think we're fine
    ... we have made it as future-compatible as possible based on past
    experience, on other groups' languages, on their recommendations
    ... we think our processing model is solid enough to handle the

    RB: I agree

    MH: I think on the mailing list we've agreed that versioning is
    built on the NS, if there's incompatibility we can change it
    ... spec grows monotonically
    ... ensure back-compat of new releases
    ... two aspects: 1) the versioning of the format, 2) versioning of
    the APIs
    ... e.g. Geolocation

    MC: the P+C doesn't concern itself with the APIs
    ... but in P+C we take the same architectural approach
    ... future-compatibility without explicity versioning
    ... because you end up with a situation whereby you need to support
    previous versions, it's heavy
    ... lots of legacy crap, like WAP, because there's content out there
    that uses it
    ... we want to avoid that

    MH: this changes my understanding
    ... you want to drop support for some APIs

    MC: no, we just want to support one evolving API built to be

    MH: you assume there will be no deprecation

    MC: yes

    RB: and if there are breaking changes we change the name — just like
    for namespaces

    Magnus: at some point you make changes, how do you determine whether
    that something has changed without versioning?

    MC: that approach doesn't work, it doesn't live up to the lifespan
    that web content has
    ... "at least 100 years" is a design principle
    ... running the same Tetris a century from now
    ... archive.org should still run
    ... it's about creating a communication medium that will stay there
    for a very very long time
    ... instead of dying after a few years
    ... pages from 1991 still work

    MH: you don't know it's from 1991

    MC: and you don't care — which is the point

    BS: that works as we have a slow transition from one language to
    another — but you expect applications to change faster

    Josh: no — on the web we expect things to keep working even if the
    author is long dead

    MC: like a dead

    Andy: I don't expect Betamax to work today

    Josh: as a user, if it has good content — I want to watch

    MC: that is a fault in the design of Betamax
    ... it's very frustrating

    RB: and it's a loss to civilisation

    BS: media conversion occurs all the time — valuable content gets

    MC: we'll still support legacy stuff

    BS: you mean if possible

    MC: no, actually support

    Benoit: a new browser created today would have to be compatible all
    the way to 19991

    MC: that's the point

    BS: in the case of APIs you may find a better way to do it

    RB: just change the name

    BS: but then you don't have to support the old ones

    RB: yes you do, there's content out there

    MH: versioning helps

    Josh, MC, Benoit, RB: no it doesn't

    Benoit: versioning only works if you can decide to support just one
    ... or deprecate some versions

    MH: it depends on the relationship between v1 and v2

    Benoit: if v2 is very different from v1, it's not v2 — it's
    something different

    BS: in principle I agree that back-compat is important
    ... but there will be cases when we leave technologies behind
    ... I think e.g. SMS will be replaced by SIP

    MC: people will still want to access them

    RB: and it's not a publishing format

    BS: but I'm talking about an API
    ... there'll be a new API, but still the old SMS API
    ... what if the device doesn't have the capability?

    Benoit: it's a capability issue

    RB: that's a capability issue, not a versioning issue

    MH: what if a browser doesn't implement all the APIs?

    RB: then it's not very useful

    AB: can we come back to the P+C spec

    MC: the @version is only for authors, it only identifies the version
    of the widget — it's just a string that humans can interpret

    MH: I wanted to change the name of this attribute

    MC: it's in line with how it's used

    MH: it's different from how it is in other W3C specifications

    AB: let's try to get some closure
    ... does anybody object to the definition in the P+C?

    MC: Marcin, what's your proposal?

    MH: @widget-version
    ... I would like someone from the TAG to review this
    ... geolocation also define a version attribute on the object
    ... for the specification version

    AB: I don't see a conflict between that and us

    MC: I can't find that on the API

    MH: it was discussed today, also with Anne
    ... if W3C is a spec vendor, then make it consistent

    RB: that's already hopeless

    <Zakim> MikeSmith, you wanted to comment

    MS: the TAG is already having a discussion about versioning
    ... co-ordination is not a constraint
    ... you don't want W3C to attempt to impose coherence at that level
    of granularity — it would grind everything to a halt

    AB: we're not going to find authority in the W3C that will tell us
    what to do

    MS: the one point in the process where that can happen is during
    ... at that point a formal objection can raise to the Director
    ... and then the Director steps in, having collected information
    from the TAG

    AB: we don't want TimBL having to step in with the naming of an

    Josh: I'm fine with a change to make the text say in its first
    sentence that @version is the version of the widget, not of anything

    <anne> fwiw, geolocation does not specify version on the object

    <anne> it is being considered by some, but that's not the same

    <anne> (and I don't think it'll happen)

    MH: I think that by doing this we are breaking the architectural
    assumption of W3C specifications
    ... elsewhere it is version of the specificaiton
    ... seen it in SVG, SML

    thanks anne

    MS: that's not true — e.g. HTML

    RB: note that those examples do not have the same semantics

    Josh: we shouldn't blacklist a word because it didn't work in other
    semantics — we want to use it for useful semantics

    MC: how can we clarify this?

    JK: it's already clear, I don't see what the confusion is

    Josh: agreed
    ... I was confused by the attribute type description — can we stick
    it after boolean, numeric (or alphabetically) so that it doesn't
    jump out so much?

    MC: yup

    AB: third time, does anybody object to the way in which the @version
    attribute has been defined?


    RESOLUTION: @version as defined in P+C LC is acceptable

    AB: any other issues to raise today?

    MC: thank you Marcin for your feedback, fixed a lot of stuff

    AB: +1
    ... is MaxF going to submit comments?

    MC: no, Lachlan and Anne are

    <ArtB> AB: this one

      [44] http://lists.w3.org/Archives/Public/public-webapps/ 

    AB: one extra topic, Scott Wilson brought up a number of good
    things, do we want to discuss some of them or is the on-list
    discussion enough to make progress?

    MC: I think we're fine for P+C — a lot of his comments recently have
    been about A+E

    AB: I have a cloudy crystal ball
    ... modulo any major issues we should be ready to go to CR
    ... what's your sense here Marcos?

    MC: it's hard to judge, the commenters I have lined up may bring up
    ... I think people on the WG have gone through it, hopefully we've
    weeded out issues
    ... I plan to finish before I go on holiday (18th)

    AB: Dan, will MWBP review?

    DKA: hasn't MWBP come back?

    AB: for LC1

    DKA: I don't think there'll be any feedback for LC2

    <scribe> ACTION: Josh to go through P+C one more time [recorded in

    AB: I don't want to get a bunch of comments on the 20th — let's not
    extend the time, it's been in LC since the beginning of the year

    <DKA> +1

    RB: should we ask the SVG WG to review?

    Josh: good idea

    <scribe> ACTION: Robin to ask the SVG WG to review (before the 19th)
    [recorded in

    <shepazu> noted

    Benoit: what does vacation mean for the CR timing?

    MC: probably July 1st

    Benoit: can't decide on the 18th

    MC: back on the 25th
    ... I should be able to ring in for the conf

    AB: we could record a decision to go forward on the 20th
    ... using a call for consensus
    ... if there are no objections, I'll then send a transition request

    DKA: we could do it on the 25th's call

    AB: ok, let's do that

    RB: I can fix the spec for pubrules if needed in MC's absence

    MC: and it should be set to go anyway

    AB: we'll cover testing tomoroow
    ... PC, AOB?

    Josh: exit criteria?

    MS: what's the plan?

    MC: I like the XBL2 criteria

    AB: I like the DigSig

    MC: it says the same thing, but wishy-washy

    Josh: I like the second sentence about openness

    AB: not sure it's clear enough

    MS: we don't need to overanalyse it, it's just about not getting the
    spec out based on some in-house implementation that can't be
    ... needs some degree of distribution and general testing

    Josh: the DigSig one requires 2 implementations of each test — not
    of the whole thing. Let's use the XBL2 version

    AB: if the implementation ships as part of a phone, does it count

    DKA: yes

    RB: yes
    ... we don't need to overlegalise it, this very same WG will decide
    when we agree to move out of CR
    ... this really is process wonking

    AB: can we not have the same EC for each spec

    RB: how about reusing DigSig, but changing two implementations of
    *each* test but two of *all* tests?
    ... it's a two word change

    [AB summarises the proposal for MC]

    <timeless_mbp> ... and demonstrated, according to the test suite,
    two interoperable implementations.

    Dave: we could even drop "each test"

    AB: anybody object to replacing " for each test" with nothing?

    MC: the XBL2 one is better but I can live with it
    ... I have made the change

    RESOLUTION: the agreed-upon DigSig CR EC will be applied to P+C and
    to all subsequent specs in this WG


    DKA: do we have a PAG call?

    MS: yes

    AB: the PAG is having weekly conferences as per process

Discussing Brian’s input

    BS: it had to do generally with the purpose for the access element v
    the feature element
    ... there were two things I proposed
    ... 1) a @required flag
    ... you get only what you declare in the way it is defined, which
    means that without prior knowledge that a specific domain is going
    to be allowed, you won't find out until it doesn't work
    ... you can't get access to things that may be useful but not
    ... <feature> was designed around that, but not <access> — which I
    find is similar in nature
    ... you could have alternate approaches if a netres is not available
    ... I based access@required on the feature

    RB: it's commented out, pushed out to v2

    BS: why defer?

    AB: I think the general reason why some of us felt we should put it
    off is because we hit LC around christmas last year, and we'd like
    to consider ourselves feature-complete

    <trackbot> Sorry... I don't know anything about this channel

    <trackbot> If you want to associate this channel with an existing
    Tracker, please say 'trackbot, associate this channel with #channel'
    (where #channel is the name of default channel for the group)

    BS: but WARP has been moved out into a separate spec

    <MikeSmith> trackbot, associate this channel with #webapps

    <trackbot> Associating this channel with #webapps...

    BS: is it assumed WARP is near LC?

    <MikeSmith> trackbot, bye

    <trackbot> Sorry... I don't know anything about this channel

    <trackbot> If you want to associate this channel with an existing
    Tracker, please say 'trackbot, associate this channel with #channel'
    (where #channel is the name of default channel for the group)

    AB: when we made that decision, it was still in PC
    ... so does the decision move with it?

    <MikeSmith> trackbot, associate this channel with #webapps

    <trackbot> Associating this channel with #webapps...

    <MikeSmith> trackbot, status

    <trackbot> This channel is not configured

    <MikeSmith> trackbot, status?

    <trackbot> This channel is not configured

    AB: the idea was that WARP should move at warp speed
    ... I suggest that the same rationale applies
    ... we don't want any new features

    MC: I still don't see much use for these attributes, so from Opera's
    point of view we don't see them as that useful

    JK: I'm indifferent about @required, but @duration is disconcerting
    ... I see a lot of echo of J2ME and the result of that is when these
    values were used and applied to mutiple different APIs it very
    quickly turns into excessive prompting

    <MikeSmith> trackbot, init

    <MikeSmith> trackbot, status

    <trackbot> This channel is not configured

    JK: that's a UX killer — if we bring that into <access> where the
    granularity is a URL, and you have several of these, you're going to
    get more prompting, and a dreadful UX

    <MikeSmith> trackbot. leave

    <MikeSmith> trackbot, leave

    RT: I agree, you're implying UX with prompting — we don't want to
    imply UX, that's an implementation thing

    MH: consolidation of the prompts?

    <MikeSmith> trackbot, associate this channel with webapps

    <trackbot> Sorry... I don't know anything about this channel

    <trackbot> If you want to associate this channel with an existing
    Tracker, please say 'trackbot, associate this channel with #channel'
    (where #channel is the name of default channel for the group)

    <MikeSmith> trackbot, associate this channel with webapps

    <trackbot> Associating this channel with webapps...

    <trackbot> Sorry... I don't know anything about this channel

    <trackbot> If you want to associate this channel with an existing
    Tracker, please say 'trackbot, associate this channel with #channel'
    (where #channel is the name of default channel for the group)

    <MikeSmith> trackbot, associate this channel with #webapps

    <trackbot> Associating this channel with #webapps...

    MH: this is an important factor

    BS: the purpose is not to mandate a UI/UX
    ... obviously apps have to be designed or vetted to access some

    <MikeSmith> trackbot, status?

    <trackbot> This channel is not configured

    <ArtB> Bryan's email:

      [47] http://lists.w3.org/Archives/Public/public-webapps/ 

    BS: the purpose of this disclosure is not to promote a given
    security model

    <MikeSmith> trackbot, status?

    <trackbot> This channel is not configured

    <MikeSmith> trackbot, leave

    BS: we will eventually have a process of alignement

    <trackbot> Sorry... I don't know anything about this channel

    <trackbot> If you want to associate this channel with an existing
    Tracker, please say 'trackbot, associate this channel with #channel'
    (where #channel is the name of default channel for the group)

    <MikeSmith> trackbot, associate this channel with #webapps

    <trackbot> Associating this channel with #webapps...

    BS: we see this process of prompting as essential

    <MikeSmith> trackbot, status?

    <trackbot> This channel is not configured

    BS: but this is just like feature@required
    ... this is about what the widget needs to be able to do

    MC: even if @required is going to be useless because the URL might
    be unavailable

    BS: but you can still have a policy

    MC: yeah, but I think it's overkill
    ... <access> says what you want to access, and then it might but
    ... so you're already handling that case

    BS: but the widget won't install

    RB: we don't say whether the widget gets installed or not

    MC: you know access@uri
    ... if it's not allowed to access something inside the range of
    URIs, the required doesn't change anything there
    ... on feature it's different but I could live with dropping it

    <MikeSmith> action-1


    <scribe> ACTION: RB to send Larry a proper response about
    "thismessage" and how it relates to Widget URI scheme
    [48]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in

      [48] http://www.rfc-editor.org/rfc/rfc2557.txt

    <trackbot> Created ACTION-354 - Send Larry a proper response about
    "thismessage" and how it relates to Widget URI scheme
    [50]http://www.rfc-editor.org/rfc/rfc2557.txt on Robin Berjon - due

      [50] http://www.rfc-editor.org/rfc/rfc2557.txt

    sorry, had to undrop it

    MC: the request would just fail

    BS: but with @reuiqred you can check that by policy
    ... you could implement APIs on the web represented as URIs much
    more flexibly, but they should be equal citizen with feature

    MC: required on feature is a legacy from when we had fallback — this
    has gone so it could go too

    RB: if we drop @required on feature we have to go back to LC

    BS: if you discover incompatibility earlier, you have a better UX

    Josh: wrong, users get pissed because they can't install the widget
    that their friend has
    ... if it bails out too early I can't use it
    ... I can show examples of this

    BS: I would prefer to not even offer that to download based on
    ... we can do this in PC, or we can do this externally

    MC: why do we assume that there will be different policies for
    different devices

    BS: we do policy per context, in MIDP and native

    MC: which are very unsuccessful

    <dom> trackbot, associate this channel with #webapps

    <trackbot> Associating this channel with #webapps...

    BS: some people chage, some people don't

    AB: the more we talk about policy, the more I think it's a DAP

    RB: thank you Art, you'll pay for that

    <JereK> +1

    <dom> trackbot, status?

    <trackbot> This channel is not configured

    <dom> ACTION-1?

    <trackbot> ACTION-1 -- Doug Schepers to find All Open Issues For
    DOM3 Events and Update the Specification -- due 2009-03-18 -- OPEN

    <trackbot> [51]http://www.w3.org/2008/webapps/track/actions/1

      [51] http://www.w3.org/2008/webapps/track/actions/1

    AB: I'm not hearing a lot of support within this WG to do it here
    ... there's an opportunity to submit furhter comments when FPWD is
    ... WARP isn't in LC, so in theory it's open to features

    emphasis on theory

    AB: I recommend ending the discussion now, and discussing when the
    FPWD is out

    MC: in the future, there's only ever going to be one policy
    ... for all devices

    RB: developers certainly would prefer that

    RESOLUTION: Policy gets discussed in DAP

    MC: we can add it in a separate spec

    BS: we'd like to avoid the overhead of addiotinal spec

    Josh: we'd like to avoid the overhead of extra attributes that turn
    out to be useless

    the WG opens a bet about the future


Summary of Action Items

    [NEW] ACTION: Art to follow up with MWBP chairs for LC comments
    [recorded in
    [NEW] ACTION: Art to ping XML Core and the XML CG about reviewing
    our PC LC [recorded in
    [NEW] ACTION: Josh to go through P+C one more time [recorded in
    [NEW] ACTION: RB to send Larry a proper response about "thismessage"
    and how it relates to Widget URI scheme
    [55]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
    [NEW] ACTION: Robin to ask the SVG WG to review (before the 19th)
    [recorded in
    [NEW] ACTION: Robin to send Larry a proper response about
    "thismessage" and how it relates to Widget URI scheme
    [58]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in
    [NEW] ACTION: Send Larry a proper response about "thismessage" and
    how it relates to Widget URI scheme
    [60]http://www.rfc-editor.org/rfc/rfc2557.txt recorded in

      [55] http://www.rfc-editor.org/rfc/rfc2557.txt
      [58] http://www.rfc-editor.org/rfc/rfc2557.txt
      [60] http://www.rfc-editor.org/rfc/rfc2557.txt

    [End of minutes]
Received on Friday, 12 June 2009 10:43:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC