Widgets F2F Meeting

11 Jun 2009

See also: IRC log


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




<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 changes.

<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 implementation.

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 it?

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 http://www.w3.org/2009/06/11-wam-minutes.html#action01]

<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: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0902.html

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: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0903.html

<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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0904.html

<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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0905.html

[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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0906.html

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

AB: Marcos?

Marcos: It's editorial.

AB: Any objections?

[no objections]

<ArtB> AB: next http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0907.html

<ArtB> [ [widgets] editorial style ]

AB: I think this is naturally editorial.

Marcos: Yes.

AB: Any objections?

[no objections]

<ArtB> AB: next is http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0908.html

<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 thing...
... 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 view.

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 ITS.

[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 initially...

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 feature-at-risk?

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 object]

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.

<timeless_mbp> http://www.w3.org/TR/its/#directionality-definition

<timeless_mbp> 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: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0909.html

<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 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: http://www.w3.org/TR/2008/WD-powder-formal-20080815/

<darobin> Transition Request notifying At Risk features: 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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0910.html

<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 100.

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

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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0911.html

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

Marcos: should you just check the file extension or actually parse...?

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 document."
... 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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0913.html

<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: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0913.html]

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

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> 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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0914.html

<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.

<darobin> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0915.html

[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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0916.html

<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 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0917.html

<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. Disagreements?


<ArtB> AB: next is http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0918.html

<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: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0922.html

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

<DKA> ScribeNick: DKA

JS: he's right...

<timeless_mbp> http://dev.w3.org/2006/waf/widgets/#step-7--process-the-configuration-docume

[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 well-formed.
... 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 well-formed...

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

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

<darobin> 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 namespace...
... you have to use a namespace aware XML parser.

AB: What's the outcome...

<timeless_mbp> 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" clause...

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> 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 widgets.

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

<ArtB> 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 eachother.

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 http://www.w3.org/2009/06/11-wam-minutes.html#action03]

<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: http://www.sitepen.com/blog/2008/07/16/jsonquery-data-querying-beyond-jsonpath/

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 http://www.w3.org/2009/06/11-wam-minutes.html#action04]

<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 signature..

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 late...

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 http://www.w3.org/2009/06/11-wam-minutes.html#action01]
[NEW] ACTION: Barstow work with DAP WG chairs on a document that describes relationships between WebApps' specs and DAP's specs [recorded in http://www.w3.org/2009/06/11-wam-minutes.html#action03]
[NEW] ACTION: Josh to look at server-side events. [recorded in http://www.w3.org/2009/06/11-wam-minutes.html#action04]
[NEW] ACTION: smith find an example of an At Risk feature [recorded in http://www.w3.org/2009/06/11-wam-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/06/11 13:12:25 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/s./is./
Succeeded: s/aiggh!//
Succeeded: s/Jere/Benoit/
Succeeded: s/[no objections]//
Succeeded: s/Yep./Correct./
Succeeded: s/server-side/server-sent/
Succeeded: s/XML HTTP Request/XMLHttpRequest/
WARNING: No scribe lines found matching ScribeNick pattern: <Dan> ...
Found ScribeNick: DKA
Found Scribe: Dan
Found ScribeNick: ArtB
Found ScribeNick: timeless_mbp
Found ScribeNick: DKA
ScribeNicks: DKA, ArtB, timeless_mbp
Present: Art Marcos Benoit Jere Mike David Magnus Laura Robin Dan Richard Josh Marcin
Found Date: 11 Jun 2009
Guessing minutes URL: http://www.w3.org/2009/06/11-wam-minutes.html
People with action items: barstow josh smith

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]