- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 12 Jun 2009 06:46:38 -0400
- To: public-webapps <public-webapps@w3.org>
The draft minutes from the June 10 Widgets f2f are available at the
following and copied below:
<http://www.w3.org/2009/06/11-wam-minutes.html>
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
Approved.
-Regards, Art Barstow
[1]W3C
[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
Attendees
Present
Art, Marcos, Benoit, Jere, Mike, David, Magnus, Laura, Robin,
Dan, Richard, Josh, Marcin
Regrets
Chair
Art
Scribe
Dan
Contents
* [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
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
[10]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:
[11]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
02.html
[11] 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:
[12]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
03.html
[12] 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
[13]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
04.html
[13] 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
[14]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
05.html
[14] 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
[15]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
06.html
[15] 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
[16]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
07.html
[16] 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
[17]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
08.html
[17] 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>
[18]http://www.w3.org/TR/its/#directionality-definition
[18] http://www.w3.org/TR/its/#directionality-definition
<timeless_mbp>
[19]http://www.iamcal.com/understanding-bidirectional-text/
[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/2009AprJun/09
09.html
[20] 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 [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/
[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
[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/2009AprJun/09
10.html
[24] 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
[25]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
11.html
[25] 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
[26]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
13.html
[26] 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:
[27]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
13.html]
[27] 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> [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/2009AprJun/09
14.html
[29] 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>
[30]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
15.html
[30] 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
[31]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
16.html
[31] 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
[32]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
17.html
[32] 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
[33]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
18.html
[33] 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:
[34]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09
22.html
[34] 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>
[35]http://dev.w3.org/2006/waf/widgets/#step-7--process-the-configur
ation-docume
[35] 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> [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
namespace...
... 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"
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.
Process
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
widgets.
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
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
[40]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:
[41]http://www.sitepen.com/blog/2008/07/16/jsonquery-data-querying-b
eyond-jsonpath/
[41] 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
[42]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
[43]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
[44]http://www.w3.org/2009/06/11-wam-minutes.html#action03]
[NEW] ACTION: Josh to look at server-side events. [recorded in
[45]http://www.w3.org/2009/06/11-wam-minutes.html#action04]
[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