See also: IRC log
<DKA> ScribeNick: DKA
<scribe> Scribe: Dan
<ArtB> Date: 11 June 2009
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).
+1
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].
<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?
[none]
<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.
+1
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.
+1
<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?
[no]
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."
[agreement]
<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?
[none]
<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.
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/
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.
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]