Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
On 18/12/11 20:31 , Marcos Caceres wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). JCD: How can you seriously state something like this ? It is so naive to think such hand waving on the spec will have any effect on how businesses adopt it and use it. See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. JCD: No! It means the spec is broken. Just because you decide on a new definition of conformance does not mean it is shared by everyone. Regards JC (speaking as coordinator of conformance in all MPEG standards between 1998 and 2006) If you were conforming yesterday, but a new version of the a spec comes out tomorrow, then you update your software to conform to the latest version. As an example, almost all Browsers are on a 6 week release cycle now: so it's quite inexcusable to expect to just conform to some dates draft and then expected to never have to update the software (i.e., conformance is an ongoing living process: specs are buggy, tests are buggy, and software is buggy… any of those can affect an conformance over time: the are all living things). Pretending that slapping a date on spec means anything is unhelpful (and actually harmful, because all specs contain bugs and hence must be continuously maintained). -- Marcos Caceres -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
On Monday, December 19, 2011 at 8:55 AM, Jean-Claude Dufourd wrote: On 18/12/11 20:31 , Marcos Caceres wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). JCD: How can you seriously state something like this ? Because it's a fact. Go and look at the specs. It is so naive to think such hand waving on the spec will have any effect on how businesses adopt it and use it. I'm not handwaving. I'm just pointing out a fact. And I don't see how you can call me naive, when it's you that hasn't even looked at the specs. See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. JCD: No! It means the spec is broken. No it's not. Just because you decide on a new definition of conformance does not mean it is shared by everyone. I didn't redefine conformance (or you don't know what conformance is?). Conformance: passing tests in a test suite. Tests represent conformance requirements in a specification. Test may be buggy. Spec may be buggy. Regards JC (speaking as coordinator of conformance in all MPEG standards between 1998 and 2006) Are you telling me that every test in the MPEG test suite was perfect and none have been changed after it became a standard? Or that no new tests needed to be added? Or that implementers found no issues with the MPEG specs?
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
Marcos You are replying beside the point everywhere. Please read again what Leonard wrote about undated references. Leonard is right. In ISO specs, undated references are forbidden. There is a team of people (called ITTF) whose job includes checking these things and bugging spec editors to fix them. There is such a thing as certification. It is impossible to do if the spec is not fixed, including references. What you are advocating is entirely counterproductive given the source of the discussion (= a PAG): if the spec has undated references, you cannot make sure it is royaltee-free. If the scope of one reference changes, there is a new risk. It is not only a problem of conformance testing. Your vision of fluid standards is completely unmanageable in practice. Regards JC On 19/12/11 12:33 , Marcos Caceres wrote: On Monday, December 19, 2011 at 8:55 AM, Jean-Claude Dufourd wrote: On 18/12/11 20:31 , Marcos Caceres wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). JCD: How can you seriously state something like this ? Because it's a fact. Go and look at the specs. It is so naive to think such hand waving on the spec will have any effect on how businesses adopt it and use it. I'm not handwaving. I'm just pointing out a fact. And I don't see how you can call me naive, when it's you that hasn't even looked at the specs. See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. JCD: No! It means the spec is broken. No it's not. Just because you decide on a new definition of conformance does not mean it is shared by everyone. I didn't redefine conformance (or you don't know what conformance is?). Conformance: passing tests in a test suite. Tests represent conformance requirements in a specification. Test may be buggy. Spec may be buggy. Regards JC (speaking as coordinator of conformance in all MPEG standards between 1998 and 2006) Are you telling me that every test in the MPEG test suite was perfect and none have been changed after it became a standard? Or that no new tests needed to be added? Or that implementers found no issues with the MPEG specs? -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
Jean-Claude, On Monday, December 19, 2011 at 12:37 PM, Jean-Claude Dufourd wrote: Marcos You are replying beside the point everywhere. Please read again what Leonard wrote about undated references. Leonard is right. I'm sorry, but Leonard is not correct: this is the W3C, not ISO. ISO is a real standards body (i.e., can be legally binding for governments). W3C is a business/community consortium (i.e., not a legal standards body and specs are not legally binding): W3C makes recommendations, which are not (and should not be) legally binding. In ISO specs, undated references are forbidden. There is a team of people (called ITTF) whose job includes checking these things and bugging spec editors to fix them. Yes, but this is not ISO. And just because they operate in that manner, it also doesn't mean that ISO is right. There is such a thing as certification. It is impossible to do if the spec is not fixed, including references. What if there is a bug in the spec? or a test is wrong and it's fixed after someone has claimed compliance? What you are advocating is entirely counterproductive given the source of the discussion (= a PAG): if the spec has undated references, you cannot make sure it is royaltee-free. Yes you can: the /latest/ always points to the latest REC. REC is royalty free. If the scope of one reference changes, there is a new risk. It is not only a problem of conformance testing. Not if the /latest/ always points to a REC (or a periodical snapshot where IPR commitments to RF have been made). Your vision of fluid standards is completely unmanageable in practice. Yet, somehow, every browser vendor manages? Seems like an enigma. Kind regards, Marcos
Re: Proposed Specification for find/findAll/matches
On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: 2. These new methods for Element may be split out to a separate interface that omits the refElements and and refNodes parameters. Yes, please. There's no point having the same interface if the behavior is totally different based on the |this| object as described. In my opinion. I did this by defining partial interfaces for each of Document, DocumentFragment and Element, rather than having a single NodeSelector interface implemented by all three. Open Issue: Should this change affect Element.querySelector() too, or leave it as currently specified? One option is to simply not do any special scope stuff in querySelector, if we suddenly have no use cases for it. I removed the refNodes stuff from querySelector, since all use cases for it are covered by find/findAll. Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. I defined the concept of a relative selector a custom grammar to handle this better. I also started updating the draft to use Selectors 4 and DOM4 references and terminology. Some DOM3 references still remain, but they'll be changed eventually. This meant the removal of terms like context node in favour of context object defined in DOM4, among others. The editor's draft is here. http://dev.w3.org/2006/webapi/selectors-api2/#the-apis -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[Bug 15266] New: I m testing the websocket, Please kindly neglect
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15266 Summary: I m testing the websocket, Please kindly neglect Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: I m testing the websocket, Please kindly neglect Posted from: 61.18.170.232 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15266] I m testing the websocket, Please kindly neglect
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15266 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
+1 for Marcos' position. If the W3C performed compliance testing, then it would perhaps be more appropriate to reference specific versions, at least in a compliance test specification. However, the W3C has historically not defined compliance test specifications or perform compliance testing of either content, servers, or clients. Instead, external organizations that do have an interest in compliance have published compliance test specifications that do make reference to specific versions. I think this approach is more appropriate and more consistent with W3C practices. This provides a compromise between the W3C's need to innovate and author and device manufacturer needs to define a level of interoperability consistent with some compliance test specifications. Many (most?) authors don't particularly care about strict compliance. Only in certain industries and content domains is compliance assigned a high priority. Let W3C specs use non-specific references where it makes sense, and let other organizations (or even the W3C if desired) define separate specifications that map these non-specific references to specific references in the context of a specific compliance test specification. Regards, Glenn On Sun, Dec 18, 2011 at 12:31 PM, Marcos Caceres w...@marcosc.com wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. If you were conforming yesterday, but a new version of the a spec comes out tomorrow, then you update your software to conform to the latest version. As an example, almost all Browsers are on a 6 week release cycle now: so it's quite inexcusable to expect to just conform to some dates draft and then expected to never have to update the software (i.e., conformance is an ongoing living process: specs are buggy, tests are buggy, and software is buggy… any of those can affect an conformance over time: the are all living things). Pretending that slapping a date on spec means anything is unhelpful (and actually harmful, because all specs contain bugs and hence must be continuously maintained). -- Marcos Caceres
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
conformance definitions are not compliance testing; i did not use the word conformance; there are (at least) four different, independent tasks here: 1. defining conformance specifications 2. defining compliance test specifications 3. performing certification (i.e., applying compliance test specifications to content, devices, etc) 4. licensing labels/brands (denoting successful certification) the W3C historically defines the first of these only; other organizations (not the W3C) have defined (2) and performed (3) and (4); i'm agreeing with Marcos and suggesting that W3C stick with (1), and to make references to both internal and external dependent specifications be non-specific (unversioned) when this makes sense, and (2) other organizations may define (2), perform (3), and license (4); in the process of defining (2), these organizations can map non-specific references to specific (versioned) references; in other words, I believe that the W3C's tasks do not necessarily have to include normatively defining specific concrete version mappings for dependent spec references; this can be accomplished in (2), which need not be done by the W3C (and indeed has not been done historically, i.e., defining the criteria for successful certification); cheers, G. On Mon, Dec 19, 2011 at 9:15 AM, Jean-Claude Dufourd jean-claude.dufo...@telecom-paristech.fr wrote: On 19/12/11 16:55 , Glenn Adams wrote: ...However, the W3C has historically not defined compliance test specifications or perform compliance testing of either content, servers, or clients... JCD: To name just the specs I know because I participated in writing them: - SVGT 1.2 appendix D: conformance criteria - CDF WICD 1.0 appendix C: conformance Then, two randomly selected RECs: - XML1.1 section 5 Conformance - XML Schema 2001 section 2.4 Conformance Or do you mean historically as in the early 90s ? I believe you are confusing certification which W3C never tried AFAIK, with conformance which is in all currently developed specs I have looked at. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
CfC: CORS to advance to Last Call
As discussed in the WebAppSec WG call on Dec 6, the editor would like to promote Cross-Origin Resource Sharing (CORS) to Last Call and this is a Call for Consensus to do so: http://www.w3.org/TR/2010/WD-cors-20100727/ This CfC satisfies the group's requirement to record the group's decision to request advancement. Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is January 3, 2012. Please send all comments to: public-webapp...@w3.orgmailto:public-webapp...@w3.org Thank you, Brad Hill
