[widgets] P&C typo in 9.1.9. Rule for Parsing a Non-negative Integer
Hi, I found a typo in 9.1.9. Rule for Parsing a Non-negative Integer. Step 8.D currently reads: "If position is not past the end of input, go to 7 in this algorithm." But should read: "If position is not past the end of input, go to 5 in this algorithm." This should have no impact on anyone who has implemented, as they would have had to performed 5 anyway (setting nextchar to be next character at position). We also have tests in the test suite that would have caught out any implementation doing this incorrectly. See, for instance: http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-BxjoiWHaMr/003/ -- Marcos Caceres http://datadriven.com.au
Re: Adopting postMessage and MessageChannel from HTML5?
On Jan 14, 2010, at 11:23 AM, ext Maciej Stachowiak wrote: On Jan 14, 2010, at 6:16 AM, Arthur Barstow wrote: The decision is that WebApps may now publish a Working Group _Note_ for postMessage and MessageChannel but we may not publish a Working Draft until this item is formally added to our Charter. Some information on the potential effects of this: I believe this will lead to Web Apps WG's Web Workers draft having a normative dependency on a Working Group Note. Web Workers is in Last Call. I believe the end of the Last Call period is before we get rechartered. Thus, we will potentially end up asking for CR transition with a WG Note normative dependency. Is that going to be acceptable? June 30 is both the expiration date of WebApps' current charter and the end of the comment period for the Web Workers LC review period. My understanding is that charter discussions will soon begin (BTW, I haven't seen any indication that anyone will object to postMessage/ MessageChannel being added to WebApps Charter). If there are no major issues raised (e.g. no one recommends the WG be split up) during the charter discussions, I would expect the re-chartering to be completed by June 30. If the timing isn't acceptable, the HTML WG may publish a WD of postMessage/MessageChannel and WebApps can take it over (after it is in WebApps' charter). -Art Barstow
Seeking pre-LCWD comments for Indexed Database API; deadline February 2
Nikunj would like to move the Indexed Database API spec to Last Call Working Draft (LCWD): http://dev.w3.org/2006/webapi/WebSimpleDB/ If you have any comments, please send them to public-webapps@w3.org by February 2. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Additionally, a LCWD should be considered feature-complete with all issues resolved. If there are other groups that should be asked for comments, please forward this email to them or identify the group(s). -Regards, Art Barstow
A Method for Writing Testable Conformance Clauses and its Applications (Was Re: Write up of test assertion extraction methodology)
Hi all, A draft of "A Method for Writing Testable Conformance Clauses and its Applications" in now available for review online [1]. For those that have not seen it, it basically just documents how we are standardizing the Widget specs and some basic QA processes: http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html Please consider this a working draft, as it likely contains typos, and a couple of half-baked ideas, etc. Comments are, of course, welcomed. It is expected that this document will be published as a working group note at some point in the future. Kind regards, Marcos Marcos Caceres wrote: Dominique Hazael-Massieux wrote: Hi Marcos, Le mardi 05 janvier 2010 à 17:45 +0100, Dominique Hazael-Massieux a écrit : Le mardi 05 janvier 2010 à 17:44 +0100, Marcos Caceres a écrit : I was literally doing an editorial pass right now. I would appreciate another day or two to finish (and for you and the WG to have a chance to review the changes). If I check-in a draft by Thursday, could we aim to publish next week? Sure, sounds good to me. Thanks for your help on this! Any news on your editing pass :) ? Sorry, I'm still working on it... it's taking a little longer than I first anticipated :( I've rewritten most of it to describe a bit more clearly how the method was applied.
Re: A Method for Writing Testable Conformance Clauses and its Applications (Was Re: Write up of test assertion extraction methodology)
Hi, Marcos- Marcos Caceres wrote (on 1/19/10 10:49 AM): Hi all, A draft of "A Method for Writing Testable Conformance Clauses and its Applications" in now available for review online [1]. For those that have not seen it, it basically just documents how we are standardizing the Widget specs and some basic QA processes: http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html Please consider this a working draft, as it likely contains typos, and a couple of half-baked ideas, etc. Comments are, of course, welcomed. It is expected that this document will be published as a working group note at some point in the future. This is an interesting doc and case study, with useful best-practices that mirror some of my own experience in creating specs and test suites. I plan on integrating this into specs I edit, where possible. I think you could emphasize algorithms a bit more, which is traditionally a weak point in W3C specs. It may or may not be appropriate for this document to discuss document readability more; W3C specs traditionally serve multiple audiences, such as implementers, tutorial/book writers, and content creators (authors), and while there is a move to make specs more implementer-focused and separate out these concerns, this decreases the value of the specs as community artifacts, makes tutorials more likely to be available only much later and to be error-prone, since they are not written by the same group of people who wrote the prose of the spec. I really like the goal and execution of this practice. Some of it reminds me of my experimental Speki [1] project, which was an exploration of a wiki toolbar to mark up specs for easier spec production. One aspect of this was to create special stylesheets for making the conformance criteria more obvious (follow the link, and select the "implementers" presentation on the sidebar for a demonstration). I applied some of this markup to DOM3 Events, but not consistently enough. This was part of my Project Tinker [2] architecture proposal (which I've neglected for a year or two). Overall, I am very supportive of this kind of detailed analysis, and I appreciate the time and care you took to develop and write it up. This kind of document stands to make the production and quality of specs much better. My chief suggestion is that, having developed your workflow and tools, you should make them available to other groups; I am interested in reusing your tools for DOM3 Events and SVG, specifically the markup and implementation report tools, and with some modification, the test suite markup and tools. SVG has its own tools and processes for some parts of this, but I strongly believe that the benefit increases the more specs use the same toolchain. Here are some specific comments, mostly typo corrections or clarification suggestions: 1. Common mistakes * For each of the commons mistakes, include corrections for the faulty prose. 2. The method * "stable identifier" may be a little vague and abstract; if you mean to add an @id, say, "give them a stable identifier, (such as) an 'id' attribute value that is consistent between drafts". If you mean something else, describe it. * Typo: "(see )" * Typo: "learnt" -> "learned" 2.1 Relationship to the standardization process * "tangible objects": it might be better to use the term "deliverables", since that is the wording of the Process Document and charters; at the least, associate the 2 terms... "tangible objects (also called the "deliverables" of the group) ..." * Include "issue tracking software" in the list of tools provided by the W3C, which can be used as part of the test/spec feedback loop. 3. Structural components of a conformance clause * "Product" might be better stated as a "Conformance Category", which includes authoring tools and authors. While tests against authored content are not in the scope for this document, editors need to be aware of the various conformance categories that they need to keep in mind when writing, of which "user agents" are only one category. DOM3 Events describes the following conformance categories: Web browsers and other dynamic or interactive user agents; Authoring tools; Authors and content; and Specifications and host languages. 4. Conventions for marking-up conformance clauses * Typo: "anylising" -> "analyzing" * Typo: "Prerequisites: <"If"" -> "Prerequisites: "If"" * Typo: "Working Groups is" -> "Working Group is" * "Hyperlink to the appropriate terms." Show, don't tell. Give us an example here, to contextualize what you mean by "the appropriate terms", even though the full example is down below: "Hyperlink to the appropriate terms. For example, "encounters a href="#file">file matching"" 5. Extracting conformance clauses * "in favor of using JavaScript" -> "in favor of using a custom JavaScript library called _"... make it easy to discuss and share * Typo: "w
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow wrote: > Nikunj would like to move the Indexed Database API spec to Last Call > Working Draft (LCWD): > > http://dev.w3.org/2006/webapi/WebSimpleDB/ > > If you have any comments, please send them to public-webapps@w3.org by > February 2. > > Note the Process Document states the following regarding the > significance/meaning of a LCWD: > > [[ > http://www.w3.org/2005/10/Process-20051014/tr.html#last-call > Purpose: A Working Group's Last Call announcement is a signal that: > > * the Working Group believes that it has satisfied its relevant technical > requirements (e.g., of the charter or requirements document) in the Working > Draft; > > * the Working Group believes that it has satisfied significant dependencies > with other groups; > > * other groups SHOULD review the document to confirm that these > dependencies have been satisfied. In general, a Last Call announcement is > also a signal that the Working Group is planning to advance the technical > report to later maturity levels. > ]] > > Additionally, a LCWD should be considered feature-complete with all issues > resolved. > > If there are other groups that should be asked for comments, please forward > this email to them or identify the group(s). > > -Regards, Art Barstow > > We (Google) support this LC publication. We would, however, like time to gather meaningful experience with the spec before the last call review period ends. We expect we'll have this experience by the end of May. Would it be permissible to have a 4 month LC review period to facilitate this? Thanks, Jeremy
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: > On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow wrote: > Nikunj would like to move the Indexed Database API spec to Last Call Working > Draft (LCWD): > > http://dev.w3.org/2006/webapi/WebSimpleDB/ > > If you have any comments, please send them to public-webapps@w3.org by > February 2. > > Note the Process Document states the following regarding the > significance/meaning of a LCWD: > > [[ > http://www.w3.org/2005/10/Process-20051014/tr.html#last-call > Purpose: A Working Group's Last Call announcement is a signal that: > > * the Working Group believes that it has satisfied its relevant technical > requirements (e.g., of the charter or requirements document) in the Working > Draft; > > * the Working Group believes that it has satisfied significant dependencies > with other groups; > > * other groups SHOULD review the document to confirm that these dependencies > have been satisfied. In general, a Last Call announcement is also a signal > that the Working Group is planning to advance the technical report to later > maturity levels. > ]] > > Additionally, a LCWD should be considered feature-complete with all issues > resolved. > > If there are other groups that should be asked for comments, please forward > this email to them or identify the group(s). > > -Regards, Art Barstow > > > We (Google) support this LC publication. > > We would, however, like time to gather meaningful experience with the spec > before the last call review period ends. We expect we'll have this > experience by the end of May. Would it be permissible to have a 4 month LC > review period to facilitate this? We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Jan 19, 2010, at 3:39 PM, Maciej Stachowiak wrote: On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow > wrote: Nikunj would like to move the Indexed Database API spec to Last Call Working Draft (LCWD): http://dev.w3.org/2006/webapi/WebSimpleDB/ If you have any comments, please send them to public-webapps@w3.org by February 2. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Additionally, a LCWD should be considered feature-complete with all issues resolved. If there are other groups that should be asked for comments, please forward this email to them or identify the group(s). -Regards, Art Barstow We (Google) support this LC publication. We would, however, like time to gather meaningful experience with the spec before the last call review period ends. We expect we'll have this experience by the end of May. Would it be permissible to have a 4 month LC review period to facilitate this? (For some reason, I didn't get Jeremy's email.) I am completely open to keeping a long enough LC period to allow everyone a chance to perform detailed review of the spec. We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. I leave it to the chair to decide the best way to schedule this. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
Re: MPEG-U
Hi Doug, Le 13/01/2010 19:59, Doug Schepers a écrit : Hi, Cyril- Cyril Concolato wrote (on 1/13/10 10:37 AM): Yes, you're right, the problem is that liaisons usually are not considered as public documents so the secretariat or MPEG members are not allowed to make them public. ... Anyway, MPEG is meeting next week, I'll raise your questions and try to have MPEG make a formal answer. Could you please make sure that the secretariat sends the email to team-liais...@w3.org, CCing Steven, Mike, and me, as the Team Contacts for the WebApps WG, and Philippe Le Hegaret as Interaction Domain Lead? It's not appropriate to email Tim Berners-Lee for liaisons at this level, though if they insist, I suppose they can include him. We need to make sure that these liaisons are dealt with in a timely manner. I would greatly appreciate if you could have the secretariat send an immediate acknowledgment email to the above email addresses, just to make sure that the process is understood and accepted, before sending the liaison itself. Could you please request that right away? I know you are doing what you can to make sure the communication channels are clear, so I appreciate your help. Just for clarification. I don't know yet if the liaison can be sent to a public mailing list. But if it is possible, is it preferable to send it directly to the public mailing list or to list of persons you mentioned? Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
For what it's worth we are in the same situation at mozilla On Jan 19, 2010 3:40 PM, "Maciej Stachowiak" wrote: On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: > On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow... We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
[selectors-api] comments on Selectors API Level 2
Hi there. (this message contains personal comments and does not represent an official response from the CSS WG) I have read the recent Selectors API Level 2 draft [1] and have a few important comments to make: 1. I don't like the idea of refNodes. I think having the APIs specified at Element level makes it confusing. I would recommend applying the NodeSelector interface to NodeList instead. If queryScopedSelector() and queryScopedSelectorAll() are applied to an Element or a NodeList, the corresponding element(s) are the refNodes of the query. Same comment for matchesSelector(). 2. I am extremely puzzled by the parsing model of scoped selectors. In particular, I think that the :scope pseudo-class introduces things that go far beyond scoping. Let's consider the selector ":scope+p". Clearly, it's _not_ scoped since it queries element that are outside of the subtree the context element is the root of. Furthermore, these elements can be queried without scopes, and I don't see why this is needed at all!!! I would recommend dropping the pseudo-class :scope and make a simpler model where a fictional :scope pseudo-class and a descendant combinator are prepended to all selectors passed as the argument of the corresponding APIs. I don't like the idea that implementors will have to check if the first sequence of simple selectors in a selector contains or does not contain a given pseudo-class to prepend something to the context. This is clearly the kind of things I think we should avoid in Selectors in general. 3. the section about :scope does not include error handling. What happens if multiple :scope are present? 4. what's the specificity of that pseudo? Since it's proposed as a regular and non-fictional pseudo, web authors _can_ use it in regular stylesheets, even if it's meaningless outside of a scoped stylesheet. What's the behaviour in that case? What's the specificity? [1] http://www.w3.org/TR/selectors-api2/ -- W3C CSS WG, Co-chair
