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

[widgets] Draft Minutes from 11 June 2009 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 12 Jun 2009 06:46:38 -0400
Message-Id: <E4D3F63F-E718-4EE1-83A2-CB64DCE14687@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the June 10 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/

                                - DRAFT -

                           Widgets F2F Meeting

11 Jun 2009

    See also: [2]IRC log

       [2] http://www.w3.org/2009/06/11-wam-irc


           Art, Marcos, Benoit, Jere, Mike, David, Magnus, Laura, Robin,
           Dan, Richard, Josh, Marcin




      * [3]Topics
          1. [4]Process and LC
          2. [5]Anne's Comments
          3. [6]Process
          4. [7]Next f2f
          5. [8]WebApps in General
      * [9]Summary of Action Items

    <DKA> ScribeNick: DKA

    <scribe> Scribe: Dan

    <ArtB> Date: 11 June 2009

Process and LC

    Art: before we start looking at Anne's comments, 2 things.
    ... first thing: a go-through of the process document to discuss the
    relevant parts relating to last call and take a look at what the
    process document says.

    [looking at "last call announcement" in process document]

    <ArtB> AB: Process doc 7.2 #2 says:

    <ArtB> [[

    <ArtB> Provide public documentation of all changes (both substantive
    and minor) to the technical report since the previous step. A
    substantive change (whether deletion, inclusion, or other
    modification) is one where someone could reasonably expect that
    making the change would invalidate an individual's review or
    implementation experience. Other changes (e.g., clarifications, bug
    fixes, editorial repairs, and minor error corrections) are minor

    <ArtB> ]]

    <ArtB> AB: the L10N model was the last part added to the P+C spec

    <ArtB> ... I would characterize the changes we agreed to make as
    "bug fixes"

    <ArtB> ... rather than substantive

    AB: [Read-through of relevant clause.]

    Benoit: we need to find out if the changes we've done are "bug
    fixes" or if it's breaking an existing implementation.

    Marcos: If we're fixing bugs in the spec then we might fix

    Robin: It's meant to leave room for [interpretation].

    Benoit: Is it possible to make a diff?

    Marcos: using HTML diff we can do that - a w3c tool.

    Art: One of our tasks is to - using these definitions - have a
    discussion about whether the changes we agreed to earlier this week
    are "substantive" or not.

    JS: In the case of the locale stuff we don't have anyone who's
    implemented a test suite.

    MS: Not sure that's valid because there could be someone who has not
    publicly disclosed their implementation.

    JS: The question is: can I "reasonably" expect that someone has
    implemented this?
    ... I would have thought someone trying to implement this would have
    complained [about locale] and would have complained

    AB: I completely understand what you're saying - but I can tell you
    that Nokia hasn't got that far. Would any other members - e.g. OMTP
    - go on record on what test cases they've created?
    ... Is it reasonable to expect that someone has done enough
    implementation of P&C such that if we make the changes we've agreed
    this week that the implementation would break?

    David: My initial read is "no."

    AB: If we agree that the changes are substantive then we have to go
    back to working draft.

    RB: You can go to a 2nd last call.

    MS: Yes that's true.

    [[minimum period was 3 weeks]

    DR: What's the change that's proposed?

    Marcos: We corrected some stuff in the internationalization
    processing. We changed the way the user agent language tags work.
    That's it.

    Jere: if we reconsider the change then we don't have this problem.

    Dan: but it's an important change.

    AB: Is it a bug fix?

    MS: No.

    AB: So what is a bug fix?

    Benoit: in a way it's a bug fix.

    AB: Mike why do you rule it out as a bug fix?

    MS: In a normal universe that would not be considered a bug fix.

    JS: How could someone reviewing it not have complained? Anyone who
    did a good job reviewing it would have noticed it.

    MS: We need to follow process. But we can do as Josh suggests - move
    forward on the assumption that nobody could have been effected by
    this change so they would have noticed the problem.

    AB: Let's remember that the last part of the document was the L10N
    part - and it [therefore] had some bugs.

    RB: And we did nothing to the spirit of the algorithm.

    MS: That's viable. We can explicitly document that [thought process]
    and move forward.

    PROPOSED RESOLUTION: The changes we've made so far to P&C are
    considered "bug fixes" (with regard to the process document).


    Marcos: Yeah OK.

    AB: Dan you agree?

    Dan: Yes I agree with Josh's logic.

    AB: I suggest substantive changes as adding new features...

    RB: Or reworking an existing feature.

    AB: Yes.

    <Bryan> +1

    <Benoit> +&

    David: Yes I agree.

    <timeless_mbp> +1

    <Benoit> +1

    <darobin> +1

    <mhanclik> +1

    MS: +0
    ... We can try it.
    ... It's gonna come down to W3M.

    AB: Anyone else want to go on record?
    ... We have consensus.

    RESOLUTION: The changes we've made so far to P&C are considered "bug
    fixes" (with regard to the process document).

    AB: Looking at this from a process POV: when we look at these
    comments - there are multiple ways they can be addressed.
    ... We do have a requirement to address every comment. We could
    accept as clarficiation, accept as bug fix, consider it a minor
    change, consider it a substantive change and agree to do it.
    ... Could we agree it should be changed but not for 1.0 - so defer

    MS: Same category.
    ... It's a viable approach.

    AB: How should we go through Anne's comments? One by one starting
    with the first...

    <Zakim> DKA, you wanted to note that we need to document this
    particular change...

    Dan: The rationale for the previous resolution needs to be
    documented for the transition request.

    <ArtB> ACTION: Barstow include this discussion in the TransReq for
    the P+C document [recorded in

    <trackbot> Created ACTION-362 - Include this discussion in the
    TransReq for the P+C document [on Arthur Barstow - due 2009-06-18].

Anne's Comments

    <ArtB> Anne:

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

    Marcos: This is purely editorial.

    <ArtB> [ [widgets] Editorial: 9x Processing ]

    Marcos: did people find this section confusing?

    Marcin: I have read it a few times - I agree it could be clearer but
    I could follow it.

    AB: Another process-related question - would it be acceptable for
    some comments to say we agree and we will make the change during CR.

    JS: I believe this is an editorial comment and it can be fixed as an
    editorial comment.

    DR: I think this is clearly editorial. To delay changing the spec
    seems strange. Why not do it now?

    AB: Don't want to overly burden the editor.

    MS: We could respond with a comment that we "plan to do a normal
    degree of editorial clean-up during CR".

    DR: This should be at the editor's discression as well.
    ... I think we should not wait.

    BS: Does he have any particular suggestions?

    Jere: I think the spec already has text on the structure.

    BS: Without specific input on what he thinks is deficient we can't
    fix it.

    Marcin: for me this is a "style" thing.

    AB: consensus for Marcos to fix this in the non-substantive
    category. Any objections?


    <ArtB> AB: next:

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

    <ArtB> [ [widgets] Rule for extracting file data from a file entry ]

    [deep contemplation]

    AB: consensus for Marcos to fix this in the non-substantive
    category. Any objections?

    Jere: [wrt use of 2119 terminology] it can be used in non-normative
    text as long as it's not marked up...

    [no objections]

    <ArtB> AB: next

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

    <ArtB> [ [widgets] Rule for dealing with an invalid Zip archive ]

    Marcos: it's editorial.

    AB: Any objections to considering this editorial?

    <ArtB> AB: next is

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

    [no objections]

    <ArtB> [ [widgets] Rule for finding a file within a widget package ]

    AB: Marcos has already responded that Anne was looking at an
    editorial draft.

    Dan: Is this taken care of by the previously recorded resolution?

    AB: Yes.

    <ArtB> AB: next is

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

    <ArtB> [ [widgets] Rule for getting a single attribute value ]

    AB: Marcos?

    Marcos: It's editorial.

    AB: Any objections?

    [no objections]

    <ArtB> AB: next

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

    <ArtB> [ [widgets] editorial style ]

    AB: I think this is naturally editorial.

    Marcos: Yes.

    AB: Any objections?

    [no objections]

    <ArtB> AB: next is

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

    <ArtB> [ [widgets] Rule for Getting Text Content ]

    JS: The ITS thing is there because the I18N group [requested] it?

    Marcos: Yes. They strongly recommended something like this.

    JS: Personally I agree with Anne. I don't understand the benefit. We
    need to explain that to the I18N people.

    AB: One way we could potentially handle this - is to mark this as a
    feature-at-risk depending on feedback from implementers.

    MS: Yes.

    Marcos: I think we should drop it from vers 1 and add it back in
    when the market demands it. If someone wants to use ITS they can use
    it. We don't add anything new or special.

    MS: The point of CR is to get implementation experience. If it's not
    implemented then it won't meet the exit criteria.

    BS: Will this be important for asian markets?

    JS: More relevant for Arabic.

    [some discussion on unicode...]

    JS: I can't think of an xml editor that would support ITS span
    without supporting the underlying unicode markers that do the same
    ... further - the goal of the markers is to show what the text will
    look like inline. An xml editor that shows things in child nodes
    wouldn't do that - so you have to support the underlying inline

    AB: Have any browsers implemented ITS span?

    [nobody knows off the top of their head]

    AB: 3 options - 1: we say the I18N community has asked us for this
    which is why it's there. 2: we remove it (substantive change). 3: we
    mark it at-risk

    JS: An Altova product does support it and they recommend it.

    Marcos: why have we chosen this technology over others?

    Jere: The people who came up with ITS are smart they are
    recommending it for a reason.
    ... Is the problem that Josh describes regarding unicode directional
    markers the same one that ITS is solving?

    JS: Yes.

    AB: [highlights relevant section - 3.2]
    ... I'm not concerned about the harmfulness of leaving it in.

    PROPOSED RESOLUTION: regarding Anne's comment on ITS, we respond
    that I18N community requested it, we added it, it's optional.

    Marcos: You need to defer to that spec - the algorithm in question
    is supposed to give you unicode with markers in place and it's not
    defined how that happens...

    Marcin: is it just because of ITS that we are refering to DOM3?

    JS: No we use DOM3 no matter what.

    Marcos: You still need DOM3.
    ... If we got rid of this, it would remove one rule as well for
    getting text content. The only reason this rule exists is to handle

    [discussion on economic models of software development]

    Marcos: My understanding is that the ITS spec slots in the unicode
    markers at specific locations...

    AB: So any user agent that uses ITS has to ...

    Benoit: this was already an issue when we talked about it

    Marcos: Taking it out doesn't trash the work - it's still the case
    that you can use any XML technology such as ITS to achieve this.

    Jere: If the user agent does not support ITS then they can go on to
    step 3 and be done with it.

    Marcin: If someone implements this and the majority of vendors do
    not support it, does it get removed from the spec?

    JS: It lives forever and nobody uses it.
    ... Most likely 0 user agents will support it.

    Marcin: Optionality is an issue - whether you should have optional
    elements in general.
    ... I would suggest to drop it because it would be deprecated from
    the very beginning.

    AB: We understand that the side effect would be back to last call.
    ... Two people are proposing it would be dropped.

    Dan: I support the previous proposal saying that it was there
    because the I18N group requested it.
    ... And leaving the spec as is.

    AB: And mark it as a feature-at-risk.

    Marcos: would you have to move back to working draft if you drop a

    AB: [displays the relevant part of the process document]

    [process document indicates that you do not have to move back to WD
    if you drop a feature-at-risk as long as the director does not

    PROPOSED RESOLUTION: regarding Anne's comment on ITS, we respond
    that I18N community requested it, we added it, it's optional.


    PROPOSED RESOLUTION: regarding Anne's comment on ITS, we respond
    that I18N community requested it, we added it, it's optional.

    PROPOSED RESOLUTION: regarding Anne's comment on ITS, we respond
    that I18N community requested it, we added it, it's optional and it
    will be marked as a feature-at-risk.


    <Benoit> +1

    <timeless_mbp> +1

    <mhanclik> +1

    RESOLUTION: regarding Anne's comment on ITS, we respond that I18N
    community requested it, we added it, it's optional and it will be
    marked as a feature-at-risk.


      [18] http://www.w3.org/TR/its/#directionality-definition


      [19] http://www.iamcal.com/understanding-bidirectional-text/

    <darobin> Marcos, ArtB: there doesn't seem to be any specific
    Process requirement as to how to flag a feature at risk, but common
    practice seems to be that it needs to be clearly flagged in the SotD
    (and optionally also in the body), and needs to have a section of
    its own in the transition request

    [short break]

    <ArtB> AB: next comment from Anne is:

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

    <ArtB> [ [widgets] Rule for Getting Text Content with Normalized
    White Space ]

    [starting up again]

    <ArtB> ACTION: smith find an example of an At Risk feature [recorded
    in [21]http://www.w3.org/2009/06/11-wam-minutes.html#action02]

    <trackbot> Created ACTION-363 - Find an example of an At Risk
    feature [on Michael(tm) Smith - due 2009-06-18].

    <darobin> Feature At Risk:

      [22] http://www.w3.org/TR/2008/WD-powder-formal-20080815/

    <darobin> Transition Request notifying At Risk features:

      [23] http://www.w3.org/2001/sw/WebOnt/rqim.html

    Jere: can Anne come up with a definitive definition of white space?

    Marcos: Editorial.

    AB: Any objections to us considering this editorial?

    [no objections]

    <ArtB> AB: next comment is

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

    <ArtB> [ [widgets] Rule for Parsing a Non-negative Integer ]

    [looking at relevant section]

    Marcos: the word "it" is ambiguous.

    [in the comment]

    AB: What's the provenance of what's documented here in the spec?
    ... Is the jist of the comment that HTML5 has changed and we need to
    reflect that?


    AB: If he's saying we need to tweak this algorithm that this would
    be a bug fix - we could action Marcos to fix the bug.

    JS: I don't think we should diverge from HTML5.

    Dan: This came from html5?

    Marcos: not it's different from HTML5...
    ... [e.g.] if you have an image with width 100 pixels or "100 200"
    the browser will correctly find the first number it hits and display

    MS: I think the only thing that needs to be removed is the last
    statement "a user agent MUST ignore leading and trailing space

    JS: Yes.
    ... Yes - it's redundant to step 6 of the documented algorithm so it
    can be removed.
    ... [hence] This is an editorial comment.

    RB: And trailing space is documented in step 7.

    AB: So it's an editorial comment. Any objections

    [no objections]

    <ArtB> AB: next

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

    <ArtB> [ [widgets] Rule for Identifying the Media Type of an Image ]

    Marcos: should you just check the file extension or actually

    JS: Are there other specs that do magic number suggestions?

    Marcos: yes HTML5.

    JS: what do they do with types that aren't magic-numberable?

    AB: Shouldn't we just remove the entry from the table?

    JS: No - the table does 3 things - lists media types, lists magic
    numbers, and comments that are broken because the comment should say
    how the magic number works...

    AB: What should it say?

    JS: The comment should say " it needs to be a well-formed XML file
    according to [svg-tiny] and if user agents happen to support it...

    RB: He might object that any xml document is correct according to
    SVG specification.
    ... The objection might be that - recognizing the file type if you
    don't have the file type or media type by parsing it and seeing if
    it's SVG is not a well-defined operation.
    ... SVG specification does not define it.
    ... His proposal is to make it that if there's no file extension you
    can't know that it's SVG.

    JS: So it's an editorial comment and we take his advice.

    RB: We say "none, see comment" and change the comment to "if the
    file extension does not indicate it you can't detect if it's an SVG
    ... And that's fine because everyone will include SVG documents with
    extension .svg anyway.

    JS: The "see comment" part needs to be changed.

    RB: The comment should say "you cannot identify SVG documents using
    a magic number."

    Jere: should we add svgz?
    ... is SVGz magic number identifiable?

    RB: No.

    Bryan: svgz could be in there.

    [agreement not to address the svgz issue right now]

    <Marcos> MC: "SVG documents cannot be identified using a magic
    number. User agents that support SVG MUST parse files in accordance
    to the [SVGTiny] specification."

    AB: any objections?
    ... Robin proposed: "SVG documents cannot be identified using a
    magic number."
    ... any objections?

    [no objections]

    Marcos: Does that address his comment?

    AB: There is another comment - on needing a leading "."

    Marcos: I put those in already.

    AB: We are going to address that as an editorial comment.

    [no objectoins]

    <ArtB> AB: next is

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

    <ArtB> [ [widgets] Rule for Identifying the media type of a file ]

    Marcos: I'm still not sure we addressed the previous email [on SVG].

    AB: I think what he's saying here is what we agreed to.

    RB: We shouldn't say "you must have the correct extension" because
    there may be other ways to identify.

    JS: So we are as crystal clear as we are willing to be.

    Marcos: So we don't need to say "it only works if you only use the
    proper extension."
    ... I think we should say "SVG can only be identified through the
    .svg file extension."

    AB: If we have to fix a bug then we'll fix a bug.

    [consensus to keep the previous agreement]

    [now moving on to next comment:

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

    Marcos: I'll fix the file extension thing as editorial - the leading

    AB: First 2 paragraphs of comment are indeed editorial.

    JS: Is audio/wav registered?
    ... [researching on a popular search engine] audio/wav doesn't
    appear to be registered.

    RB: It's not in the IANA registry.

    <darobin> [28]http://www.iana.org/assignments/media-types/audio/

      [28] http://www.iana.org/assignments/media-types/audio/

    JS: So our response should be that audio/wave and audio/wav are not
    registered so we can't reference.
    ... It seems clear that there is no "e" in x-wav

    Marcos: Let's get rid of ".wave" and just have ".wav."

    JS: Yes I think he's right on that - again it's editorial.

    RB: We can add the extra column during CR.

    AB: next comment.

    <ArtB> AB: next is

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

    <ArtB> [ [widgets] Rule for Determining if a potential Zip archive
    is a Zip archive ]

    AB: a short comment...

    [looking at relevant part of document]

    RB: I don't see how it's not testable.
    ... It's option but it's testable.
    ... A user agent that doesn't do it doesn't fail but you can test
    one that does do it.


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

    [we are actually discussing link pasted by darobin]

    JS: For a web server you can test it by seeing if the server has
    served all the bytes?

    RB: It's saying that user agents are allowed to optimize by only
    analyzing the first 4 bytes.
    ... I don't think you should drop it.

    JS: I think he's suggesting it could be rephrased as non-normative.

    RB: It is non-normative.

    Marcos: let's change it to a note.

    AB: Would that be considered substantive?

    JS: No.

    RB: No.

    AB: We do not think this is a substantive change.
    ... We have agreement to change it to a note.

    [no objections]

    <ArtB> AB: next comment

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

    <ArtB> [ [widgets] Verify Zip archive ]

    Jere: there are no folders in the zip file just zip relative paths.

    JS: It could be done but would be substantive.

    AB: We thought about it and we excluded it.

    Benoit: It's faster to process...

    JS: In reality it doesn't matter.

    RB: We answer "yes it would be nice we'll think about it some day."

    JS: "We think it might be nice and someone might offer a tool..."

    RB: Reality is that people will have to use a tool anyway.

    AB: Any more discussion required?

    Marcos: conclusion / response should be "yes it would be nice but no
    thank you."


    <ArtB> AB: next comment is

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

    <ArtB> [ [widgets] One element is allowed per language: ]

    JS: It's in step 7.
    ... Third description doesn't belong to this example.

    AB: This is clearly editorial.

    [discussion on what change to make]

    AB: Any objections to giving Marcos the license to change this as he
    sees fit?

    [no objections]

    Jere: 2nd sentence...

    AB: Why don't we just deleted that 3rd description element?

    RB: The question being asked is regarding the paragraph before that
    to accommodate cases where there is no xml:lang

    BS: If there is no language element then the first one one without a
    language element matches so it is covered by the normative text.

    AB: We've adequately addressed both comments in that email.


    <ArtB> AB: next is

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

    <ArtB> [ [widgets] Elements are grouped by language: ]

    [solemn contemplation

    [looking at text]

    <ArtB> ScribeNick: ArtB

    JS: this could use an example
    ... Marcos recommended an icon example; that makes sense
    ... if one lang has 1 icon and another lang has 10 icons

    <timeless_mbp> ScribeNick: timeless_mbp

    <ArtB> Scribe+ Josh

    JS: And the locale list first has the lang with the 1 icon and then
    the lang with 10 icons
    ... Then the user agent when it looks for icons will only select the
    1 icon, excluding all icons from any other languages that it might
    have considered matching

    MC: I need to address this as suggested by anne

    JS: And this calls for two examples, the second is the default case

    <ArtB> AB: any objections to MC's proposal?

    <ArtB> [ None ]

    <ArtB> AB: next comment:

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

    <ArtB> [ [widgets] Step 7 - Process the Configuration Document ]

    <DKA> ScribeNick: DKA

    JS: he's right...


      [35] http://dev.w3.org/2006/waf/widgets/#step-7--process-the- 

    [going to relevant part of spec]

    RB: Editorial. Easy to fix.

    Jere: I think we do include introductory material that covers this.

    AB: Marcos?

    Marcos: I agree [with the comment.]

    AB: With respect to the 2nd comment -

    RB: You could change step 2 to say "namespace well-formed" instead
    of "well formed."

    JS: By the time you reach step 2 you don't have a choice because it
    wouldn't have got to step 2 if the doc was not namespace
    ... at 3 you have a null document. At 4 you don't have a <widget>
    element so it's invalid. So it is possible.
    ... between the namespace parser giving null if it's not

    RB: We can change step 2 to say "namespace well-formed" and it's not

    <Marcos> "If the document is not namespace well-formed [XML],
    terminate this algorithm and treat this widget package as an invalid
    Zip archive."

    <darobin> [36]http://www.w3.org/TR/xml-names11/

      [36] http://www.w3.org/TR/xml-names11/

    <darobin> "To conform to this specification, a processor MUST report
    violations of namespace well-formedness"

    Marcos: if you don't have a namespace then it's in the null
    ... you have to use a namespace aware XML parser.

    AB: What's the outcome...

    <timeless_mbp> [37]http://www.w3.org/TR/xml-names11/#Conformance

      [37] http://www.w3.org/TR/xml-names11/#Conformance

    AB: On to the 3rd comment.

    Marcos: I'll add it for each one - it's not a significant change.

    [discussion on how to re-write]

    Marcos: I'll rewrite so it uses the same style as the preceding
    steps. I'll treat them on an individual case.

    AB: Any objections?
    ... To that approach to the third comment of that email.

    [no objections]

    RB: No it's not repeating.
    ... It's not repeating - it's saying any other attribute.

    AB: Should we as for clarification?
    ... I think all we need to do is drop "...and the user agent"

    Marcos: I will remove the "and" clause.

    AB: Any objections?

    [no objections]

    AB: We've covered all of Anne's comments.
    ... No substantive changes required.

    JS: Correct.


    Benoit: who makes the decision? Will the next call after the last
    call period we make the decision to publish?

    AB: I think we said (agreed) that if there are no substantial
    comments by the 20th then we can request transition on the 20th.
    ... My expectation would be - when I send that transition request I
    would neeed to include a "disposition of comments" document.

    MS: Yes.

    AB: We now have a single document that incorporates all our
    discussion (these minutes).
    ... Could we say "anne - our response is in the minutes."?

    Marcos: no because the changes haven't been implemented.

Next f2f

    AB: Plan of record is to meet at Technical Plenary.
    ... Not expecting to have another f2f meeting before that.

    Benoit: any ideas beyond that?

    AB: That's too far out for right now.

    RB: DAP will probably have its first meeting at TPAC.

    [discussion on TPAC agenda]

    <darobin> [38]http://www.w3c.sn/

      [38] http://www.w3c.sn/

WebApps in General

    AB: The plan of record is that we have 2 chairs. I've been focusing
    on widgets. [chaals is focusing on other other stuff] In general
    comments are always welcome and new blood is always welcome.
    ... It's a lot less structured then the way we've been handling

    RB: (e.g.) DOM3 events, CORS, File Upload, DOM, Clipboard, ...

    <ArtB> [39]http://www.w3.org/2008/webapps/wiki/PubStatus

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

    Bryan: Within Webapps group over all there is a lot you could
    leverage in a web runtime environment potentially by widgets. Is
    there any kind of overview on the timeline of how they relate to

    RB: They tend to be defined so they don't need to relate to
    eachother. Timeline is to do with resources.

    <ArtB> ACTION: Barstow work with DAP WG chairs on a document that
    describes relationships between WebApps' specs and DAP's specs
    [recorded in

    <trackbot> Created ACTION-364 - Work with DAP WG chairs on a
    document that describes relationships between WebApps' specs and
    DAP's specs [on Arthur Barstow - due 2009-06-18].

    <darobin> JSONQuery/JSONPath:

      [41] http://www.sitepen.com/blog/2008/07/16/jsonquery-data- 

    MS: Workers spec [split out of HTML5] has legs.

    JS: CORS is making progress.

    MS: Clipboard is part of html5 so superceded.

    JS: File Upload - massive update.
    ... Media Object - no info
    ... Progress is making progress.
    ... Server-side events: no info.
    ... Web IDL - making progress.

    RB: Server-side events making progress as a specification.

    Bryan: This could be related to OMA Push.

    <scribe> ACTION: Josh to look at server-side events. [recorded in

    <trackbot> Created ACTION-365 - Look at server-sent events. [on Josh
    Soref - due 2009-06-18].

    JS: Web Storage is kaput.

    RB: Web storage issues have been brought up by multiple parties -
    e.g. Dojo.

    JS: Storage needs to go back to drawing board.
    ... Web Workers - making progress. Browser makers are working
    through issues.

    AB: Web Signing - it has been replaced by widgets digital

    Dan: Web Signing could be important to BONDI for web applications.

    RB: It could rear its head again.

    Bryan: If we have a discussion in DAP as to why Web Signing is
    required that would be helpful.

    JS: SSL isn't sufficient because the browsers don't reflect the
    signatures into the web page and by the time the page loads it's too

    Bryan: I will follow up on that.

    JS: Window Object - moving forward in HTML5.

    MS: Window will not move out of HTML5.

    JS: It's progressing but not here.
    ... XBL2 - Browser makers are side-tracked with other things.

    [XBL2 is awaiting implementation]

    Dan: is anyone else besides mozilla doing XBL2?

    AB: Apple [may] also do something...

    Marcos: Opera does not comment on future products.

    MS: In webkit they made very little progress.

    JS: It's still very much wanted because it offers solutions to
    various problems.

    RB: THere's a partial javascript implementation.

    JS: XML HTTP Request. It'll finish up soon.
    ... XMLHttpRequest level 2. people are working to enhance it.
    ... There are some things of interest to us - like DOM3 load and
    save which someone needs to kill.

    RB: Trying to kill DOM3 load and save was always part of the plan.

    JS: XML Http request is how we plan to do that.

    Bryan: We had some things in BONDI that we had to do as potential
    extensions to XMLHttpRequest ...

    RB: The approach taken to XHR was to not have different policies in
    different contexts but to have one policy that would make sense in
    all cases.
    ... There was a lot of care around that.

Summary of Action Items

    [NEW] ACTION: Barstow include this discussion in the TransReq for
    the P+C document [recorded in
    [NEW] ACTION: Barstow work with DAP WG chairs on a document that
    describes relationships between WebApps' specs and DAP's specs
    [recorded in
    [NEW] ACTION: Josh to look at server-side events. [recorded in
    [NEW] ACTION: smith find an example of an At Risk feature [recorded
    in [46]http://www.w3.org/2009/06/11-wam-minutes.html#action02]

    [End of minutes]
Received on Friday, 12 June 2009 10:52:41 UTC

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