Re: WebIDL Spec Status
On Jun 26, 2014, at 9:18 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 25 Jun 2014, Glenn Adams wrote: On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson i...@hixie.ch wrote: Compraing implementations to anything but the very latest draft is not only a waste of time, it's actively harmful to interoperability. At no point should any implementor even remotely consider making a change from implementing what is currently specified to what was previously specified, that would literally be going backwards. That sounds reasonable, but its not always true (an exception to every rule, eh). For example, in order to ship a device that must satisfy compliance testing to be certified, e.g., to be granted a branding label, to satisfy a government mandate, etc., it may be necessary to implement and ship support for an earlier version. For pointless certification purposes, you can use any random revision of the spec -- just say what the revision number is and use that (and honestly, who cares how well you implement that version -- it's not like the testing process is going to be thorough). Don't ship that, though. Snapshotting a specification is valuable for implementors as well. If I refer to a living standard page, then fragment ID or terminology used in the specification may change in 5-10 years, and I would have no idea what kind of specification the person committed a given code change was following. It's also valuable to ensure the self consistency of such a snapshot since editors often refactor specifications to better structure, etc... but that tends to introduce dangling definitions or references and other inconsistencies in them. I do agree that the current long process/practice to move a specification to REC is harmful. We should streamline it as much as possible. - R. Niwa
RE: WebIDL Spec Status
From: Ryosuke Niwa rn...@apple.com Snapshotting a specification is valuable for implementors as well. If I refer to a living standard page, then fragment ID or terminology used in the specification may change in 5-10 years, and I would have no idea what kind of specification the person committed a given code change was following. It's also valuable to ensure the self consistency of such a snapshot since editors often refactor specifications to better structure, etc... but that tends to introduce dangling definitions or references and other inconsistencies in them. While I generally agree with Hixie and other living standard proponents, I want to acknowledge that these are real and practical concerns that we have not spent enough time addressing, IMO. Off the top of my head, a good solution would be to produce URLs for every changeset, so that you can reference how the spec looked at a point in time. (Similar to the GitHub URL you get by pressing the y key on any page, e.g. [1].) This would help reinforce the idea that the implementation captures the state of the spec as of the time the implementation was written, without lending any false legitimacy to the likely-outdated snapshot. In other words, it is clearer to future readers that if the spec has changed from the version listed at the given URL, then the code is outdated and needs updating. [1]: https://github.com/whatwg/streams/blob/f83cbbd2b6199c8d5a8e9a8e77759b64786524f4/index.bs I will probably experiment with this for the streams spec, e.g. including a permalink to this revision link and probably also adding the y-key functionality. Any such snapshots would have an annoying floating warning banner, of course.
Re: WebIDL Spec Status
On Jul 2, 2014, at 9:26 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ryosuke Niwa rn...@apple.com Snapshotting a specification is valuable for implementors as well. If I refer to a living standard page, then fragment ID or terminology used in the specification may change in 5-10 years, and I would have no idea what kind of specification the person committed a given code change was following. It's also valuable to ensure the self consistency of such a snapshot since editors often refactor specifications to better structure, etc... but that tends to introduce dangling definitions or references and other inconsistencies in them. While I generally agree with Hixie and other living standard proponents, I want to acknowledge that these are real and practical concerns that we have not spent enough time addressing, IMO. Off the top of my head, a good solution would be to produce URLs for every changeset, so that you can reference how the spec looked at a point in time. (Similar to the GitHub URL you get by pressing the y key on any page, e.g. [1].) This would help reinforce the idea that the implementation captures the state of the spec as of the time the implementation was written, without lending any false legitimacy to the likely-outdated snapshot. In other words, it is clearer to future readers that if the spec has changed from the version listed at the given URL, then the code is outdated and needs updating. Yeah, I always encourage patch authors to do this in WebKit. Just as an example, a hyperlink I got in Feb 2013 [1] to the WHATWG HTML spec no longer works today. To me, Feb 2013 is not a long time ago and the fact I don't have an easy way of figuring out what the specification looked like at the time, or how it has changed since then is a serious problem since I don't have the luxury of following every spec. change due to the time restraints. There are other ways to mitigate these issues in addition to publishing every revision of a given specification. For example, spec authors could list support every historical terminology and fragmentation ever introduced. We could even create some service/database to map such historical names to the new ones, explaining the difference. [1] http://whatwg.org/html#the-difference-between-the-field-type,-the-autofill-field-name,-and-the-input-modality - R. Niwa
Re: WebIDL Spec Status
On Wed, Jul 2, 2014 at 9:46 AM, Ryosuke Niwa rn...@apple.com wrote: There are other ways to mitigate these issues in addition to publishing every revision of a given specification. For example, spec authors could list support every historical terminology and fragmentation ever introduced. We could even create some service/database to map such historical names to the new ones, explaining the difference. I've been meaning to add a feature to Bikeshed to make it easier to specify the old id for a heading/dfn that changed its id for some reason, to help support this kind of thing. ~TJ
Re: WebIDL Spec Status
On Wed, 2 Jul 2014, Ryosuke Niwa wrote: On Jul 2, 2014, at 9:26 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ryosuke Niwa rn...@apple.com Snapshotting a specification is valuable for implementors as well. If I refer to a living standard page, then fragment ID or terminology used in the specification may change in 5-10 years, and I would have no idea what kind of specification the person committed a given code change was following. Yeah, it can be useful to look at old revisions for historical reasons. That's nothing like the W3C REC process (or even WD process) though. It applies just as much to individual revisions between WDs (let alone RECs). Off the top of my head, a good solution would be to produce URLs for every changeset, so that you can reference how the spec looked at a point in time. For the WHATWG HTML spec (and maybe other WHATWG specs, I'm not sure), there is a copy of the generated spec in source control, which we could expose. I've been reluctant to do so to avoid people ending up on obsolete versions (e.g. by following links from old source code) and not realising what's going on. Just as an example, a hyperlink I got in Feb 2013 [1] to the WHATWG HTML spec no longer works today. [1] http://whatwg.org/html#the-difference-between-the-field-type,-the-autofill-field-name,-and-the-input-modality That specific one worked fine for me just now, FWIW. To me, Feb 2013 is not a long time ago and the fact I don't have an easy way of figuring out what the specification looked like at the time, or how it has changed since then is a serious problem since I don't have the luxury of following every spec. change due to the time restraints. If you need anything like this don't hesitate to reach out to me. I'm happy to provide old revisions, diffs, or whatever. If you're looking for when something changed in HTML, this can be useful; it's a cached set of blame files for some interesting revisions: http://www.whatwg.org/specs/web-apps/current-work/blames-list.cgi You can also use anonymous SVN at svn.whatwg.org if you want to grab specific things directly yourself. There are other ways to mitigate these issues in addition to publishing every revision of a given specification. For example, spec authors could list support every historical terminology and fragmentation ever introduced. We could even create some service/database to map such historical names to the new ones, explaining the difference. That's a lot of work, and we already have more work than people. But as Tab said, we can probably do a better job of keeping old IDs around. I've definitely tried to do that more in recent years (though not perfectly), but there's a lot more that we could do. If you have any specific ideas, don't hesitate to let me know. (In particular, right now I'm working on a new publication pipeline for HTML and so I'm in a good position to add new features for this kind of thing.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: WebIDL Spec Status
From: Ian Hickson i...@hixie.ch I've been reluctant to do so to avoid people ending up on obsolete versions (e.g. by following links from old source code) and not realising what's going on. This is the danger, but I think an appropriately-annoying danger sign mitigates it significantly. I was going to link to the picture spec as my favorite example, but they seem to have made it less annoying (by moving it to the bottom instead of the middle), which is sad. So I made this example instead: http://jsbin.com/mutefami/1/
RE: WebIDL Spec Status
On Wed, 2 Jul 2014, Domenic Denicola wrote: From: Ian Hickson i...@hixie.ch I've been reluctant to do so to avoid people ending up on obsolete versions (e.g. by following links from old source code) and not realising what's going on. This is the danger, but I think an appropriately-annoying danger sign mitigates it significantly. I was going to link to the picture spec as my favorite example, but they seem to have made it less annoying (by moving it to the bottom instead of the middle), which is sad. So I made this example instead: http://jsbin.com/mutefami/1/ Yeah, that's an interesting idea. I've filed a bug to track this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Wed, Jul 2, 2014 at 11:10 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ian Hickson i...@hixie.ch I was going to link to the picture spec as my favorite example, but they seem to have made it less annoying (by moving it to the bottom instead of the middle), which is sad. That's for consistency with the messages used elsewhere. Also, it means it's still *possible* to use the draft if you need to. That said, it's still a very annoying message, so you shouldn't worry about that. (It also fades the rest of the page, making it even harder to use unintentionally.) ~TJ
Re: WebIDL Spec Status
On Thu, Jun 26, 2014 at 10:18 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 25 Jun 2014, Glenn Adams wrote: On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson i...@hixie.ch wrote: Compraing implementations to anything but the very latest draft is not only a waste of time, it's actively harmful to interoperability. At no point should any implementor even remotely consider making a change from implementing what is currently specified to what was previously specified, that would literally be going backwards. That sounds reasonable, but its not always true (an exception to every rule, eh). For example, in order to ship a device that must satisfy compliance testing to be certified, e.g., to be granted a branding label, to satisfy a government mandate, etc., it may be necessary to implement and ship support for an earlier version. For pointless certification purposes, you can use any random revision of the spec -- just say what the revision number is and use that (and honestly, who cares how well you implement that version -- it's not like the testing process is going to be thorough). Don't ship that, though. Whatever you ship should be regularly kept up to date with changes to the spec as they occur. (It's not an option to not be able to ship fixes, since otherwise you'd be unable to fix security vulnerabilities either, which is obviously a non-starter.) What you ship, and subsequent revisions thereto, is what you should be spending any serious amount of time testing. And for that, you shouldn't use a snapshot, you should use the latest revision of the spec. For the pointless certification, just as for the patent coverage, we should publish whatever revision we have and just stamp it as a REC. It doesn't matter what bugs it has. We know it'll have bugs -- the day after it's published, maybe even earlier, we'll find new bugs that will need fixing. It doesn't really matter, since it's not for use by implementors, just by lawyers and pointless certification teams. I would respond, but it would be ... pointless. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Fri, 27 Jun 2014, Glenn Adams wrote: For pointless certification purposes, you can use any random revision of the spec -- just say what the revision number is and use that (and honestly, who cares how well you implement that version -- it's not like the testing process is going to be thorough). Don't ship that, though. Whatever you ship should be regularly kept up to date with changes to the spec as they occur. (It's not an option to not be able to ship fixes, since otherwise you'd be unable to fix security vulnerabilities either, which is obviously a non-starter.) What you ship, and subsequent revisions thereto, is what you should be spending any serious amount of time testing. And for that, you shouldn't use a snapshot, you should use the latest revision of the spec. For the pointless certification, just as for the patent coverage, we should publish whatever revision we have and just stamp it as a REC. It doesn't matter what bugs it has. We know it'll have bugs -- the day after it's published, maybe even earlier, we'll find new bugs that will need fixing. It doesn't really matter, since it's not for use by implementors, just by lawyers and pointless certification teams. I would respond, but it would be ... pointless. I'm guessing you misinterpreted what I said, specifically, that you interpreted the pointless in pointless certification as an insult of some sort. To clarify, I did not mean it that way; I meant it literally, as in, specifically the kinds of certifications that you may be required to pursue for political or bureaucratic reasons but which have no practical purpose, as opposed to the kind of certification that serves an important purpose, like certifying that some software that's going to run a rocket passes all its tests. Certifying that software passes tests for an obsolete version of a standard, when the standard's purpose is interoperability and achieving that interoperability requires converging on a target that we're only slowly reaching over many years, is at best pointless, and at worst harmful, which is why I stand by the advice above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Fri, Jun 27, 2014 at 10:29 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 27 Jun 2014, Glenn Adams wrote: For pointless certification purposes, you can use any random revision of the spec -- just say what the revision number is and use that (and honestly, who cares how well you implement that version -- it's not like the testing process is going to be thorough). Don't ship that, though. Whatever you ship should be regularly kept up to date with changes to the spec as they occur. (It's not an option to not be able to ship fixes, since otherwise you'd be unable to fix security vulnerabilities either, which is obviously a non-starter.) What you ship, and subsequent revisions thereto, is what you should be spending any serious amount of time testing. And for that, you shouldn't use a snapshot, you should use the latest revision of the spec. For the pointless certification, just as for the patent coverage, we should publish whatever revision we have and just stamp it as a REC. It doesn't matter what bugs it has. We know it'll have bugs -- the day after it's published, maybe even earlier, we'll find new bugs that will need fixing. It doesn't really matter, since it's not for use by implementors, just by lawyers and pointless certification teams. I would respond, but it would be ... pointless. I'm guessing you misinterpreted what I said, specifically, that you interpreted the pointless in pointless certification as an insult of some sort. To clarify, I did not mean it that way; I meant it literally, as in, specifically the kinds of certifications that you may be required to pursue for political or bureaucratic reasons but which have no practical purpose, as opposed to the kind of certification that serves an important purpose, like certifying that some software that's going to run a rocket passes all its tests. No, I did not take it as an insult. I have too thick a skin to be insulted. In any case, most insults thrown my way are probably true. :) My use of pointless was intended to mean that it is pointless to argue with you about whether certification required by political or bureaucratic reasons (by which I understand you to include legal reasons as well) is or is not pointless to use your phrase. Clearly I don't agree with your position. Certifying that software passes tests for an obsolete version of a standard, when the standard's purpose is interoperability and achieving that interoperability requires converging on a target that we're only slowly reaching over many years, is at best pointless, and at worst harmful, which is why I stand by the advice above. We have different understandings of the meaning of interoperability. My interpretation of your definition of interoperability is that it is a ghost: in the sense that it has no fixed point of reference, i.e., no fixed set of specifications against which it (interoperability) can be certified. Clearly we operate in different business regimes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Fri, 27 Jun 2014, Glenn Adams wrote: Clearly we operate in different business regimes. If we both operate on the same Web content, then I don't think that matters, the interoperability issue is the same either way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On 6/25/14 11:58 AM, Glenn Adams wrote: In the case of WebIDL, my personal preference would be to not spend precious effort on WebIDL 1 CR, but instead to: (1) publish WebIDL 1 CR as a WG Note without attempting to resolve outstanding issues, other than by clearly annotating the existence of those issues in the Note; (2) focus on moving WebIDL 2E (2nd edition) to FPWD and thence to LC, etc. If this process is followed, then it also may be useful to relabel these two works a bit, e.g., by calling what is now WebIDL CR something like WebIDL Legacy in a WG Note, and then using the generic name WebIDL for what is now called WebIDL 2E. Just an idea to consider. Well, I admit I like this proposal, quite a lot actually, however, I don't know if it will satisfy the relevant process requirements (f.ex. [NormRef]). (Perhaps I should move this proposal to the public-w3process list ...) Phillippe, Yves, Cindy - what are your thoughts on Glenn's proposal for v1? Glenn - would your v1 WG Note proposal satisfy all of the WebIDL reference cases that concern you (I'm wondering in particular about specs from other SSOs that reference WebIDL)? All - feedback on Glenn's proposal is certainly welcome. -Thanks, AB [NormRef] http://www.w3.org/2013/09/normative-references
Re: WebIDL Spec Status
On Thu, Jun 26, 2014 at 4:52 AM, Arthur Barstow art.bars...@gmail.com wrote: On 6/25/14 11:58 AM, Glenn Adams wrote: In the case of WebIDL, my personal preference would be to not spend precious effort on WebIDL 1 CR, but instead to: (1) publish WebIDL 1 CR as a WG Note without attempting to resolve outstanding issues, other than by clearly annotating the existence of those issues in the Note; (2) focus on moving WebIDL 2E (2nd edition) to FPWD and thence to LC, etc. If this process is followed, then it also may be useful to relabel these two works a bit, e.g., by calling what is now WebIDL CR something like WebIDL Legacy in a WG Note, and then using the generic name WebIDL for what is now called WebIDL 2E. Just an idea to consider. Well, I admit I like this proposal, quite a lot actually, however, I don't know if it will satisfy the relevant process requirements (f.ex. [NormRef]). (Perhaps I should move this proposal to the public-w3process list ...) Phillippe, Yves, Cindy - what are your thoughts on Glenn's proposal for v1? Glenn - would your v1 WG Note proposal satisfy all of the WebIDL reference cases that concern you (I'm wondering in particular about specs from other SSOs that reference WebIDL)? The reference cases I'm working with (primarily DLNA specs) dereference WebIDL via the HTML5 references list, which in turn, refers to WebIDL 2E. So at this point, I have no issue with the existing CR being moved to a WG Note. Given the limited editorial resources, I prefer effort going into progressing 2E. All - feedback on Glenn's proposal is certainly welcome. -Thanks, AB [NormRef] http://www.w3.org/2013/09/normative-references
Re: WebIDL Spec Status
On Thu, Jun 26, 2014 at 3:47 PM, Yves Lafon yla...@w3.org wrote: I'm not a fan of shelving v1, I'd rather remove the ECMAscript binding from v1 and keep only the syntax (v2 should contain everything as there are additions to the syntax). Because? Who is going to supply resources for that? IDL has three to six months of outstanding bugs. Talking about taking it to REC without having resources to work on it at all seems vastly premature. Let alone dealing with this whole v1/v2 mess. -- http://annevankesteren.nl/
Re: WebIDL Spec Status
On Wed, 25 Jun 2014, Glenn Adams wrote: On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson i...@hixie.ch wrote: Compraing implementations to anything but the very latest draft is not only a waste of time, it's actively harmful to interoperability. At no point should any implementor even remotely consider making a change from implementing what is currently specified to what was previously specified, that would literally be going backwards. That sounds reasonable, but its not always true (an exception to every rule, eh). For example, in order to ship a device that must satisfy compliance testing to be certified, e.g., to be granted a branding label, to satisfy a government mandate, etc., it may be necessary to implement and ship support for an earlier version. For pointless certification purposes, you can use any random revision of the spec -- just say what the revision number is and use that (and honestly, who cares how well you implement that version -- it's not like the testing process is going to be thorough). Don't ship that, though. Whatever you ship should be regularly kept up to date with changes to the spec as they occur. (It's not an option to not be able to ship fixes, since otherwise you'd be unable to fix security vulnerabilities either, which is obviously a non-starter.) What you ship, and subsequent revisions thereto, is what you should be spending any serious amount of time testing. And for that, you shouldn't use a snapshot, you should use the latest revision of the spec. For the pointless certification, just as for the patent coverage, we should publish whatever revision we have and just stamp it as a REC. It doesn't matter what bugs it has. We know it'll have bugs -- the day after it's published, maybe even earlier, we'll find new bugs that will need fixing. It doesn't really matter, since it's not for use by implementors, just by lawyers and pointless certification teams. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On Tue, Jun 24, 2014 at 8:28 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jun 2014, Boris Zbarsky wrote: On 6/24/14, 1:05 PM, Glenn Adams wrote: Such device certification regimes cannot work unless the referenced specifications are locked down and clearly implementable. I see. So this is not about actual spec implementations or spec authors but effectively about a QA cycle that compares the implementations to the specs, and which needs to know which spec to compare the implementations to. Compraing implementations to anything but the very latest draft is not only a waste of time, it's actively harmful to interoperability. At no point should any implementor even remotely consider making a change from implementing what is currently specified to what was previously specified, that would literally be going backwards. That sounds reasonable, but its not always true (an exception to every rule, eh). For example, in order to ship a device that must satisfy compliance testing to be certified, e.g., to be granted a branding label, to satisfy a government mandate, etc., it may be necessary to implement and ship support for an earlier version. In the case of WebIDL, my personal preference would be to not spend precious effort on WebIDL 1 CR, but instead to: (1) publish WebIDL 1 CR as a WG Note without attempting to resolve outstanding issues, other than by clearly annotating the existence of those issues in the Note; (2) focus on moving WebIDL 2E (2nd edition) to FPWD and thence to LC, etc. If this process is followed, then it also may be useful to relabel these two works a bit, e.g., by calling what is now WebIDL CR something like WebIDL Legacy in a WG Note, and then using the generic name WebIDL for what is now called WebIDL 2E. Just an idea to consider.
Re: WebIDL Spec Status
On Tue, 24 Jun 2014, at 10:45, Glenn Adams wrote: On Mon, Jun 23, 2014 at 3:05 PM, Marcos mar...@marcosc.com wrote: Even if we were able to take the V1 bits to Rec (a lot of which is now obsolete), the V2 stuff is already widely supported and heavily relied on by browser vendors. IMO, it's a waste of everyone's time to try to maintain multiple versions. I agree that the V1 CR should be abandoned or replaced with a completed snapshot of V2. Though it would be useful to ask a wider community about the value of moving some flavor of V1 to REC. What's the benefits from having a REC based on v1 even if we know it is already obsolete? -- Mounir
Re: WebIDL Spec Status
On 6/23/14 4:04 PM, Glenn Adams wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Hi Glenn, All, I don't have any new info re v1 beyond what Boris said a few weeks ago in this thread: http://lists.w3.org/Archives/Public/public-script-coord/2014AprJun/0162.html. Cameron, Boris - please reply to Glenn's question. Given the high degree of dependency from other specs and implementations on this work, we really need to find a way to wrap up this work or at least publish something reasonably stable. I think the new(ish) normative reference policy [1] provides some guidance on how to handle this situation (and WebApps has been able to advance several of its specs to REC despite them having a normative reference to Web IDL). Are there specific specs (and Web IDL features) that concern you, Glenn? -Thanks, AB [1] http://www.w3.org/2013/09/normative-references Regards, Glenn
Re: WebIDL Spec Status
On Tue, 24 Jun 2014 16:11:23 +0600, Mounir Lamouri mou...@lamouri.fr wrote: On Tue, 24 Jun 2014, at 10:45, Glenn Adams wrote: On Mon, Jun 23, 2014 at 3:05 PM, Marcos mar...@marcosc.com wrote: Even if we were able to take the V1 bits to Rec (a lot of which is now obsolete), the V2 stuff is already widely supported and heavily relied on by browser vendors. IMO, it's a waste of everyone's time to try to maintain multiple versions. I agree that the V1 CR should be abandoned or replaced with a completed snapshot of V2. Though it would be useful to ask a wider community about the value of moving some flavor of V1 to REC. What's the benefits from having a REC based on v1 even if we know it is already obsolete? People who can happily use the obsolete version, but need something stable, can refer to a well-known version they use, that others can also use. This gives far better, although incomplete, interoperability than if everyone who wants a stable reference more than something they have to invest in watching, and reacting to, continuously, refers to a random update. cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: WebIDL Spec Status
On Mon, 23 Jun 2014 22:05:55 +0100, Marcos mar...@marcosc.com wrote: On June 23, 2014 at 4:07:09 PM, Glenn Adams (gl...@skynav.com) wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? The plan is based on an editor who is provided by Mozilla, but who is very often too busy to work on the spec. We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Given the high degree of dependency from other specs and implementations on this work, we really need to find a way to wrap up this work or at least publish something reasonably stable. That relies on someone to the the Work™. IMO, we should just concede that this document needs to be a Living Standard (tm). IMO (ie chair hat off) that would be a Really Dumb Idea™. While there is no reason to believe it would solve the problem of Heycam's availability, it would assume everyone using the spec the time to watch out for changes, and is somehow in a position to change their implementations or explain the problem in such a way as to convince the group. Given that this requires a commitment on the part of many people that probably exceeds the amount of time the editor himself spends, it seems a very expensive way to try working around a relatively simple problem. This would result in a fragile and probably increasingly fragmented ecosystem, without the minimal measure of interoperability that is gained by common references to known stable versions. Trying to move this through the W3C process is clearly not working. Even if we were able to take the V1 bits to Rec (a lot of which is now obsolete), the V2 stuff is already widely supported and heavily relied on by browser vendors. IMO, it's a waste of everyone's time to try to maintain multiple versions. Everyone is not trying to do so. A couple of people in the whole world are. A lot of everyone would benefit from the periodic publication of stable versions. While nobody is offering an editor who can get the work done, this argument is in any case academic (unless the editor's availability is predicated on the outcome, in which case it would be mere political machinations). just my 2 kopecks -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: WebIDL Spec Status
On 6/24/14, 6:56 AM, Charles McCathie Nevile wrote: While nobody is offering an editor who can get the work done, this argument is in any case academic (unless the editor's availability is predicated on the outcome, in which case it would be mere political machinations). I strongly disagree with that characterization. The fact is, for browser vendors a stable v1 Web IDL snapshot as we have right now is not very useful, since that's not what they need to implement in practice: there are too many APIs currently being specified that cannot be expressed in that snapshot. So it's really hard to justify devoting resources to such a snapshot. On the other hand, making Web IDL reflect ongoing specification reality is something that's really useful to browser vendors, so it might be easier to convince them to spend time on that. No political machinations involved. A more recent snapshot might be more useful, but is still likely to end up not being an actual implementation target because there are still too many changes happening in terms of ES integration and the like. I don't have a good solution to this problem, unfortunately. :( On the other hand, the only audience I see for a snapshot are specification writers who don't want/need the newer things we're adding to Web IDL. Are there other audiences? Are there actually such specification writers? The recent set of changes to Web IDL have all been driven by specification needs. -Boris
Re: WebIDL Spec Status
On Tue, Jun 24, 2014 at 7:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/24/14, 6:56 AM, Charles McCathie Nevile wrote: While nobody is offering an editor who can get the work done, this argument is in any case academic (unless the editor's availability is predicated on the outcome, in which case it would be mere political machinations). I strongly disagree with that characterization. The fact is, for browser vendors a stable v1 Web IDL snapshot as we have right now is not very useful, since that's not what they need to implement in practice: there are too many APIs currently being specified that cannot be expressed in that snapshot. So it's really hard to justify devoting resources to such a snapshot. On the other hand, making Web IDL reflect ongoing specification reality is something that's really useful to browser vendors, so it might be easier to convince them to spend time on that. No political machinations involved. A more recent snapshot might be more useful, but is still likely to end up not being an actual implementation target because there are still too many changes happening in terms of ES integration and the like. I don't have a good solution to this problem, unfortunately. :( On the other hand, the only audience I see for a snapshot are specification writers who don't want/need the newer things we're adding to Web IDL. Are there other audiences? Are there actually such specification writers? The recent set of changes to Web IDL have all been driven by specification needs. There are organizations attempting to create device certification regimes based on specifications that normatively reference HTML5, DOM4, XHR2, Canvas2D, WebGL, etc, and many other W3C API specs all of which have a normative dependency on the WebIDL in the sense that they must implement IDL features in ECMAScript according to the ECMAScript binding semantics in WebIDL, which, in turn become dependencies for testing. Such device certification regimes cannot work unless the referenced specifications are locked down and clearly implementable. Having a WebIDL that is always in a state of flux makes such work well nigh impossible or at best extremely difficult and untrustworthy. -Boris
Re: WebIDL Spec Status
On 6/24/14, 1:05 PM, Glenn Adams wrote: Such device certification regimes cannot work unless the referenced specifications are locked down and clearly implementable. I see. So this is not about actual spec implementations or spec authors but effectively about a QA cycle that compares the implementations to the specs, and which needs to know which spec to compare the implementations to. In an ideal alignment of incentives, the organizations that need this sort of snapshot would step up to produce it, but I'm not sure how likely that is to happen in practice... -Boris
Re: WebIDL Spec Status
On Tue, Jun 24, 2014 at 11:08 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/24/14, 1:05 PM, Glenn Adams wrote: Such device certification regimes cannot work unless the referenced specifications are locked down and clearly implementable. I see. So this is not about actual spec implementations or spec authors but effectively about a QA cycle that compares the implementations to the specs, and which needs to know which spec to compare the implementations to. Not at all. This is not about one or even a group of organizations or about QA. It is about fulfilling the process goals of the W3C and the WebApps WG. The primary goal of the W3C is to produce Technical Reports that reach a stable level of maturity. The charter of each WG includes the creating of technical reports at the REC maturity level, i.e., undergo the REC track process. If a WG fails to move a technical report to REC then it has failed its chartered purpose (as far as that report is concerned). Alternatively, it could formally decide to abandon the work by moving it to a WG Note, which implies it won't be further progressed to REC. The W3C has customers other than browser vendors. It portrays itself as a standards organization (at least informally) and talks about its work products being standards (at least informally). Standards organizations must move their work to some status that is recognized as complete, otherwise they will become a joke in the larger community of SDOs and customers. In my capacity in this WG, I represent a Full Member who pays for membership in order to see technical work reach completion. An ED or a CR does not represent completion. They are willing to help wherever possible, and devote considerable resources to the W3C at large. If at the end of the day I have to tell them that key technical work, such as WebIDL, will never reach REC, and that means that most key specifications (HTML5, DOM4) are technically incomplete or at least untrustworthy (as concrete, well-defined technical works), then it will have a negative impact on their use of those specs as well as a negative impact on future investment in the W3C process. In the current situation, I think the best course would be for the chair and team members of this group to attempt to work with the editor to define a reasonable schedule for moving it forward to REC, and, if necessary call for volunteer co-editors if the current editor is unable to invest sufficient time to see through that process. [I would note that Cameron has done and is doing an outstanding job, but appears to be negatively impacted by constant requests for new IDL features by ongoing spec writers.] The bottom line is this about fulfilling the WhatWG charter and the W3C process goals. In an ideal alignment of incentives, the organizations that need this sort of snapshot would step up to produce it, but I'm not sure how likely that is to happen in practice... -Boris
Re: WebIDL Spec Status
On 6/24/14, 1:46 PM, Glenn Adams wrote: The primary goal of the W3C is to produce Technical Reports that reach a stable level of maturity. The Technical Reports are not an end in themselves. They're a means to an end. This is why we don't produce Technical Reports that just say do whatever if we can avoid it, because that would fail to fulfill our _actual_ goals (which might differ for different W3C members of course; for some of them maybe do whatever is good enough for their purposes). You're correct that sometimes the production of the Technical Report is viewed as an end in itself in an attempt to bridge the different member's actual goals. Sometimes this works ok, and sometimes the result is a TR that is useless to some subset of members. I happen to be affiliated with a member for whom most TRs (possibly all of them) as practiced by the W3C tend to be somewhat useless compared to the process of putting together the TR, so I have certain biases in that regard. If a WG fails to move a technical report to REC then it has failed its chartered purpose (as far as that report is concerned). Yes, agreed, as the W3C process is set up right now. It's a bug, not a feature. ;) In my capacity in this WG, I represent a Full Member who pays for membership in order to see technical work reach completion. Is this Member willing to devote resources to getting there? Again, I'm not saying we shouldn't have a REC of Web IDL. I'm saying that currently there's a perverse incentives problem: the only people who have stepped up to edit the spec are the ones who are affiliated with a Member which can'e make much use of a Web IDL REC in its current state all that much. Which means that they end up, consciously or not, not prioritizing reaching REC on Web IDL v1, say, particularly highly. In the current situation, I think the best course would be for the chair and team members of this group to attempt to work with the editor to define a reasonable schedule for moving it forward to REC, and, if necessary call for volunteer co-editors if the current editor is unable to invest sufficient time to see through that process. Yep, we agree. -Boris
Re: WebIDL Spec Status
On Tue, Jun 24, 2014 at 11:57 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/24/14, 1:46 PM, Glenn Adams wrote: The primary goal of the W3C is to produce Technical Reports that reach a stable level of maturity. The Technical Reports are not an end in themselves. They're a means to an end. This is why we don't produce Technical Reports that just say do whatever if we can avoid it, because that would fail to fulfill our _actual_ goals (which might differ for different W3C members of course; for some of them maybe do whatever is good enough for their purposes). You're correct that sometimes the production of the Technical Report is viewed as an end in itself in an attempt to bridge the different member's actual goals. Sometimes this works ok, and sometimes the result is a TR that is useless to some subset of members. I happen to be affiliated with a member for whom most TRs (possibly all of them) as practiced by the W3C tend to be somewhat useless compared to the process of putting together the TR, so I have certain biases in that regard. If a WG fails to move a technical report to REC then it has failed its chartered purpose (as far as that report is concerned). Yes, agreed, as the W3C process is set up right now. It's a bug, not a feature. ;) In my capacity in this WG, I represent a Full Member who pays for membership in order to see technical work reach completion. Is this Member willing to devote resources to getting there? They are. By having me test IDL features, by having me report them to Cameron, by having me participate in this WG. Are you asking if they can supply an editor? That would best be handled by having the chairs issue a call for volunteers for co-editor on WebIDL. Again, I'm not saying we shouldn't have a REC of Web IDL. I'm saying that currently there's a perverse incentives problem: the only people who have stepped up to edit the spec are the ones who are affiliated with a Member which can'e make much use of a Web IDL REC in its current state all that much. Which means that they end up, consciously or not, not prioritizing reaching REC on Web IDL v1, say, particularly highly. In the current situation, I think the best course would be for the chair and team members of this group to attempt to work with the editor to define a reasonable schedule for moving it forward to REC, and, if necessary call for volunteer co-editors if the current editor is unable to invest sufficient time to see through that process. Yep, we agree. -Boris
Re: WebIDL Spec Status
On June 24, 2014 at 2:33:41 PM, Glenn Adams (gl...@skynav.com) wrote: They are. By having me test IDL features, by having me report them to Cameron, by having me participate in this WG. Are you asking if they can supply an editor? That would best be handled by having the chairs issue a call for volunteers for co-editor on WebIDL. Anyone can edit the spec. It's just a github repo. Send a PR. There is no need for a special call from the Chairs as an excuse to do work. -- Marcos Caceres
Re: WebIDL Spec Status
On Tue, Jun 24, 2014 at 12:36 PM, Marcos mar...@marcosc.com wrote: On June 24, 2014 at 2:33:41 PM, Glenn Adams (gl...@skynav.com) wrote: They are. By having me test IDL features, by having me report them to Cameron, by having me participate in this WG. Are you asking if they can supply an editor? That would best be handled by having the chairs issue a call for volunteers for co-editor on WebIDL. Anyone can edit the spec. It's just a github repo. Send a PR. There is no need for a special call from the Chairs as an excuse to do work. I realize you think that zero process is the best process, but I don't agree. Becoming a co-editor should be a public commitment and not simply random PRs. The chairs are well advised to call for volunteers if that is needed. -- Marcos Caceres
Re: WebIDL Spec Status
On 24/06/14 20:50, Arthur Barstow wrote: On 6/23/14 4:04 PM, Glenn Adams wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Hi Glenn, All, I don't have any new info re v1 beyond what Boris said a few weeks ago in this thread: http://lists.w3.org/Archives/Public/public-script-coord/2014AprJun/0162.html. Cameron, Boris - please reply to Glenn's question. I've put Web IDL work on my list of Q3 goals, so I will resume work on it next month. I still think that before publishing another draft on TR/ that we should resolve the open issues that apply to v1. Boris and I will be dividing up the open issues to split the work.
Re: WebIDL Spec Status
On Tue, Jun 24, 2014 at 3:28 PM, Cameron McCormack c...@mcc.id.au wrote: On 24/06/14 20:50, Arthur Barstow wrote: On 6/23/14 4:04 PM, Glenn Adams wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Hi Glenn, All, I don't have any new info re v1 beyond what Boris said a few weeks ago in this thread: http://lists.w3.org/Archives/Public/public-script-coord/ 2014AprJun/0162.html. Cameron, Boris - please reply to Glenn's question. I've put Web IDL work on my list of Q3 goals, so I will resume work on it next month. I still think that before publishing another draft on TR/ that we should resolve the open issues that apply to v1. Boris and I will be dividing up the open issues to split the work. Sounds good.
Re: WebIDL Spec Status
And also, I'd note that the general rough consensus from Google is that /TR/ tend to be far less valuable than TRs in flight, so to speak. Although I'm personally understanding of the need to checkpoint and have firm targets for precisely the reason Glenn mentions, I'd point out that the current implementations of the Process make that process so incredibly slow as to make TRs generally obsolete. On Tue, Jun 24, 2014 at 12:57 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 6/24/14, 1:46 PM, Glenn Adams wrote: The primary goal of the W3C is to produce Technical Reports that reach a stable level of maturity. The Technical Reports are not an end in themselves. They're a means to an end. This is why we don't produce Technical Reports that just say do whatever if we can avoid it, because that would fail to fulfill our _actual_ goals (which might differ for different W3C members of course; for some of them maybe do whatever is good enough for their purposes). You're correct that sometimes the production of the Technical Report is viewed as an end in itself in an attempt to bridge the different member's actual goals. Sometimes this works ok, and sometimes the result is a TR that is useless to some subset of members. I happen to be affiliated with a member for whom most TRs (possibly all of them) as practiced by the W3C tend to be somewhat useless compared to the process of putting together the TR, so I have certain biases in that regard. If a WG fails to move a technical report to REC then it has failed its chartered purpose (as far as that report is concerned). Yes, agreed, as the W3C process is set up right now. It's a bug, not a feature. ;) In my capacity in this WG, I represent a Full Member who pays for membership in order to see technical work reach completion. Is this Member willing to devote resources to getting there? Again, I'm not saying we shouldn't have a REC of Web IDL. I'm saying that currently there's a perverse incentives problem: the only people who have stepped up to edit the spec are the ones who are affiliated with a Member which can'e make much use of a Web IDL REC in its current state all that much. Which means that they end up, consciously or not, not prioritizing reaching REC on Web IDL v1, say, particularly highly. In the current situation, I think the best course would be for the chair and team members of this group to attempt to work with the editor to define a reasonable schedule for moving it forward to REC, and, if necessary call for volunteer co-editors if the current editor is unable to invest sufficient time to see through that process. Yep, we agree. -Boris
Re: WebIDL Spec Status
On 25/06/14 09:02, Arthur Barstow wrote: OK, thanks for the update Cameron. Would you please remind us how the v1 bugs are designated at such? With [v1] in the status whiteboard field of the bug. (There's still a bunch of list email I need to go through and file bugs for so the list will grow.) All - if the progression of the v1 spec is important to you, then I presume Cameron and Boris would welcome PRs (spec is at [GH] and the bugs are at [Bugs]). Indeed, and please prefer to file bugs rather than raise GitHub issues, to avoid tracking in multiple places.
Re: WebIDL Spec Status
On Tue, 24 Jun 2014, Boris Zbarsky wrote: On 6/24/14, 1:05 PM, Glenn Adams wrote: Such device certification regimes cannot work unless the referenced specifications are locked down and clearly implementable. I see. So this is not about actual spec implementations or spec authors but effectively about a QA cycle that compares the implementations to the specs, and which needs to know which spec to compare the implementations to. Compraing implementations to anything but the very latest draft is not only a waste of time, it's actively harmful to interoperability. At no point should any implementor even remotely consider making a change from implementing what is currently specified to what was previously specified, that would literally be going backwards. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL Spec Status
On June 23, 2014 at 4:07:09 PM, Glenn Adams (gl...@skynav.com) wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Given the high degree of dependency from other specs and implementations on this work, we really need to find a way to wrap up this work or at least publish something reasonably stable. IMO, we should just concede that this document needs to be a Living Standard (tm). Trying to move this through the W3C process is clearly not working. Even if we were able to take the V1 bits to Rec (a lot of which is now obsolete), the V2 stuff is already widely supported and heavily relied on by browser vendors. IMO, it's a waste of everyone's time to try to maintain multiple versions. -- Marcos Caceres
Re: WebIDL Spec Status
On Mon, Jun 23, 2014 at 3:05 PM, Marcos mar...@marcosc.com wrote: On June 23, 2014 at 4:07:09 PM, Glenn Adams (gl...@skynav.com) wrote: What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We have now a two year old CR that appears to be stuck and a 2nd Edition that I'm not sure has made it to FPWD. Given the high degree of dependency from other specs and implementations on this work, we really need to find a way to wrap up this work or at least publish something reasonably stable. IMO, we should just concede that this document needs to be a Living Standard (tm). I don't mind there being a living standard form of the document. But that is not sufficient. There must be some final REC version of some edition/snapshot of this work that provides a non-movable mark for real-world compliance testing and device certification. Trying to move this through the W3C process is clearly not working. There is no reason it can't or shouldn't. Even if we were able to take the V1 bits to Rec (a lot of which is now obsolete), the V2 stuff is already widely supported and heavily relied on by browser vendors. IMO, it's a waste of everyone's time to try to maintain multiple versions. I agree that the V1 CR should be abandoned or replaced with a completed snapshot of V2. Though it would be useful to ask a wider community about the value of moving some flavor of V1 to REC. -- Marcos Caceres
