RE: Obsolescence notices on old specifications, again
On Fri, 27 Jan 2012, Adrian Bateman wrote: I will wait to see the proposed text but in the meantime point out that Microsoft has regulatory obligations that require us to direct customers to these specifications until such time as there is a completed Recommendation that succeeds them. As a consequence we want to make sure these customers recognise that these are the most up-to-date completed specifications from W3C and are not confused by such a notice. In that case we should definitely just publish what we have now in DOM4 as a REC. It's far more complete than the decade-old DOM2 specs are. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Obsolescence notices on old specifications, again
Hello, since when is obsolete the same as work in progress? How does HTML4 (can be considered obsolete) the same as HTML5(in progress)? It only means that new features are added to HTML5 not to HTML 4 and any error in HTML 4 is ignored... This discussion is about using word obsolete in simple sentence, that is clear to developers or usage of language that would be more comfortable to politicians and high management, some complicated sentence, that is more politically correct. Again the question is: should we care? Should W3C creates new mechanism to reflect current speed of progress instead of bound progress by decade and 1/2 old processes? Should W3C creates some guidelines for understanding current state of work for external entities, that those have to understand that specs can become obsolete, that people can be explicitly discouraged from implementing them and is can happen anytime to any spec without any control of such external entities? On 24.1.2012 20:33, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. 2012/1/24 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com Hello, I do understand the objection, but how relevant should it be here? If some regulation/law dictates that work must follow e.g. DOM 2, than it does not matter that it's obsolete... The law takes precedence here regardless of status of the document. Technically in such case one don't need to worry himself about any progress or status of such document or specification. On 23.1.2012 19:06, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. Brona Brona
Re: Obsolescence notices on old specifications, again
Hello Just to be perfectly clear here... I do not think we should phrase document statuses according to some external needs, because in this case we may end up with phrasing fitting Glenns needs, but it may not be fitting other legislatures or other companies internal needs and then what? Brona On 25.1.2012 10:10, Bronislav Klučka wrote: Hello, since when is obsolete the same as work in progress? How does HTML4 (can be considered obsolete) the same as HTML5(in progress)? It only means that new features are added to HTML5 not to HTML 4 and any error in HTML 4 is ignored... This discussion is about using word obsolete in simple sentence, that is clear to developers or usage of language that would be more comfortable to politicians and high management, some complicated sentence, that is more politically correct. Again the question is: should we care? Should W3C creates new mechanism to reflect current speed of progress instead of bound progress by decade and 1/2 old processes? Should W3C creates some guidelines for understanding current state of work for external entities, that those have to understand that specs can become obsolete, that people can be explicitly discouraged from implementing them and is can happen anytime to any spec without any control of such external entities? On 24.1.2012 20:33, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. 2012/1/24 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com Hello, I do understand the objection, but how relevant should it be here? If some regulation/law dictates that work must follow e.g. DOM 2, than it does not matter that it's obsolete... The law takes precedence here regardless of status of the document. Technically in such case one don't need to worry himself about any progress or status of such document or specification. On 23.1.2012 19:06, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. Brona Brona
Re: Obsolescence notices on old specifications, again
Hi All - I just chatted with Ms2ger in IRC about his proposal [1]. Ms2ger will submit proposed text to the list so we should probably hold off on additional comments until we get that proposal. (I agree rescinding is not what we want to do for these specs.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0245.html On 1/24/12 7:26 AM, ext Charles McCathieNevile wrote: On Tue, 24 Jan 2012 11:02:55 +0100, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote: * Ms2ger wrote: The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. If you want to say more than that the specifications are no longer being maintained and which newer specifications might contain more recent de- finitions for the features covered you will have to create a process for that first (it would require Advisory Committee review for instance, as otherwise you are likely to create unnecessary drama). I should have been clearer; this is indeed all I intend to say. OK, this looks like the sort of message that Opera would support. As Art said, I think we need individual proposals per spec. And I am not sure that rescinding specs we don't like much is necessarily a good idea. cheers
Re: Obsolescence notices on old specifications, again
On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote: * Ms2ger wrote: The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. If you want to say more than that the specifications are no longer being maintained and which newer specifications might contain more recent de- finitions for the features covered you will have to create a process for that first (it would require Advisory Committee review for instance, as otherwise you are likely to create unnecessary drama). I should have been clearer; this is indeed all I intend to say. HTH Ms2ger
Re: Obsolescence notices on old specifications, again
Ms2ger, Last September, some obsolescence text was added to the DOM 2 Views REC: [[ http://www.w3.org/TR/DOM-Level-2-Views/#notice-20110922 http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/ *Document Status Update 2011-09-22*: This paragraph is informative. The concepts this document defines are obsolete. The 'document' and 'defaultView' attributes are defined in the HTML5 http://www.w3.org/TR/html5/ specification with simplified semantics. The Web Applications Working Group http://www.w3.org/2008/webapps/ encourages implementation of these concepts as defined by HTML5. ]] I think the proponents for adding obsolescence text to the other RECs should make a specific proposal for each REC. -AB On 1/23/12 4:01 AM, ext Ms2ger wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
Re: Obsolescence notices on old specifications, again
On Tue, 24 Jan 2012 11:02:55 +0100, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote: * Ms2ger wrote: The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. If you want to say more than that the specifications are no longer being maintained and which newer specifications might contain more recent de- finitions for the features covered you will have to create a process for that first (it would require Advisory Committee review for instance, as otherwise you are likely to create unnecessary drama). I should have been clearer; this is indeed all I intend to say. OK, this looks like the sort of message that Opera would support. As Art said, I think we need individual proposals per spec. And I am not sure that rescinding specs we don't like much is necessarily a good idea. cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 4:58 AM, Arthur Barstow art.bars...@nokia.comwrote: Ms2ger, Last September, some obsolescence text was added to the DOM 2 Views REC: [[ http://www.w3.org/TR/DOM-**Level-2-Views/#notice-20110922http://www.w3.org/TR/DOM-Level-2-Views/#notice-20110922 http://www.w3.org/TR/2000/REC-**DOM-Level-2-Views-20001113/http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/ *Document Status Update 2011-09-22*: This paragraph is informative. The concepts this document defines are obsolete. The 'document' and 'defaultView' attributes are defined in the HTML5 http://www.w3.org/TR/html5/ specification with simplified semantics. The Web Applications Working Group http://www.w3.org/2008/**webapps/http://www.w3.org/2008/webapps/ encourages implementation of these concepts as defined by HTML5. ]] I think the proponents for adding obsolescence text to the other RECs should make a specific proposal for each REC. I would support a notice akin to this, however, I am concerned about using the term obsolete without having a normative substitute/replacement to reference. I realize that the potential substitutes are not yet in REC status, and will take some time to get there, and that it is possible to add informative references to work in progress, but this doesn't quite satisfy my notion of what obsolete means.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 12:32 AM, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Jan 23, 2012 at 10:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. Which laws or regulations require compliance with some of the above-mentioned specs? Have bugs been filed on those laws and regulations? I am referring to laws, regulations, and formal processes adopted by various governments (e.g., U.S. and EU) and recognized international standards organizations (e.g., ITU). One does not file bugs against laws and regulations of this type. The industry I am referring to is television broadcast, cable, satellite, and broadband services, much of which is subject to national and international laws and regulations, some of which refer (directly or indirectly) to W3C RECs, including the DOM RECs being discussed here. With very few exceptions, the processes that govern these laws and regulations require that any externally referenced document be final, which, in the W3C process, means REC.
Re: Obsolescence notices on old specifications, again
Hello, I do understand the objection, but how relevant should it be here? If some regulation/law dictates that work must follow e.g. DOM 2, than it does not matter that it's obsolete... The law takes precedence here regardless of status of the document. Technically in such case one don't need to worry himself about any progress or status of such document or specification. On 23.1.2012 19:06, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. Brona
Re: Obsolescence notices on old specifications, again
On 01/24/2012 08:33 PM, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Not at all; it's a work on which progress has stopped long ago.
Re: Obsolescence notices on old specifications, again
On Tue, 24 Jan 2012, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. It should be: DOM2 (a stale document) is obsolete. Use DOM4 (a work that is actively maintained). It doesn't demote DOM2 to a work in progress, because a work in progress is a step _up_ from where DOM2 is now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Obsolescence notices on old specifications, again
I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same as saying DOM2 is a WIP. This is because the former can be read as saying that the normative content of DOM2 is now replaced with DOM4. I'm not sure what you mean by [DOM2] is a work on which progress has stopped. DOM2 is a REC, and is only subject to errata [1] and rescinding [2]. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind I'm not sure where the proposed obsolescence message falls in terms of [1] or [2]. Perhaps you could clarify, since presumably the process document will apply to any proposed change. On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 08:33 PM, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Not at all; it's a work on which progress has stopped long ago.
Re: Obsolescence notices on old specifications, again
Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com wrote: I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same as saying DOM2 is a WIP. This is because the former can be read as saying that the normative content of DOM2 is now replaced with DOM4. I'm not sure what you mean by [DOM2] is a work on which progress has stopped. DOM2 is a REC, and is only subject to errata [1] and rescinding [2]. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind I'm not sure where the proposed obsolescence message falls in terms of [1] or [2]. Perhaps you could clarify, since presumably the process document will apply to any proposed change. On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 08:33 PM, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Not at all; it's a work on which progress has stopped long ago.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. It should be: DOM2 (a stale document) is obsolete. Use DOM4 (a work that is actively maintained). It would be more accurate perhaps to say that DOM4 is a work that is under active development. In the minds of most readers, maintenance is an errata process that follows completion (REC status). It doesn't demote DOM2 to a work in progress, because a work in progress is a step _up_ from where DOM2 is now. Many (most?) government, industry, and business activities that formally utilize W3C specifications would view a work in progress as less mature than a REC. That results in the form being assigned a lower value than the latter. So, yes, demote is the correct word. I understand your agenda is to reverse this way of thinking. I have no objection to that agenda per se. But it is not an agenda shared by many members of the W3C. If you think I'm wrong about this, then I'd like to see a poll or ballot that quantifies the membership's perspective on this issue.
Re: Obsolescence notices on old specifications, again
2012/1/24 Glenn Adams gl...@skynav.com The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Clearly we need to be careful with our choice of words, though in this case I wouldn't go as far as saying a stale document becomes a work in progress when clearly the work in progress is a step forward and the state document is the one no longer progressing. But let's not perpetuate this back-and-forth. How about we get some proposed verbiage for individual specs and discuss further at that point. I think we all agree that a notice in some form would be beneficial as long as its intent is clear. 2012/1/24 Bronislav Klučka bronislav.klu...@bauglir.com Hello, I do understand the objection, but how relevant should it be here? If some regulation/law dictates that work must follow e.g. DOM 2, than it does not matter that it's obsolete... The law takes precedence here regardless of status of the document. Technically in such case one don't need to worry himself about any progress or status of such document or specification. On 23.1.2012 19:06, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. Brona
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 11:50 AM, Glenn Adams gl...@skynav.com wrote: On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. It should be: DOM2 (a stale document) is obsolete. Use DOM4 (a work that is actively maintained). It would be more accurate perhaps to say that DOM4 is a work that is under active development. In the minds of most readers, maintenance is an errata process that follows completion (REC status). I don't think the distinctions you are making here really matter. How about: DOM2 is no longer updated. DOM4 is under active development. link to DOM4. It doesn't demote DOM2 to a work in progress, because a work in progress is a step _up_ from where DOM2 is now. Many (most?) government, industry, and business activities that formally utilize W3C specifications would view a work in progress as less mature than a REC. That results in the form being assigned a lower value than the latter. So, yes, demote is the correct word. You keep saying this throughout this thread without pointing to specifics. It's impossible to argue with broad, sweeping generalizations like this. So far, you have yet to point to one concrete organization/statute that cares about REC status.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org wrote: You keep saying this throughout this thread without pointing to specifics. It's impossible to argue with broad, sweeping generalizations like this. So far, you have yet to point to one concrete organization/statute that cares about REC status. Ojan, apparently you are not familiar with international or national standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I could give you a list of hundreds if you wish, all having encoded such rules into their formal processes.
Re: Obsolescence notices on old specifications, again
I like Glenn's idea of being verbose to avoid ambiguity. It is a spec---might as well spell out the consequences of the notice. :) Andres Riofrio riofr...@gmail.com 2012/1/24 Glenn Adams gl...@skynav.com 2012/1/24 Ojan Vafai o...@chromium.org Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 That doesn't really work for me. What would work for me is something like: Although DOM Level 2 continues to be subject to Errata Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, it is no longer being actively maintained. Content authors and implementers are encouraged to consider the use of newer formulations of the Document Object Model, including DOM4 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance .
Re: Obsolescence notices on old specifications, again
On 1/24/12 8:58 PM, Glenn Adams wrote: 2012/1/24 Ojan Vafai o...@chromium.org mailto:o...@chromium.org Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 That doesn't really work for me. What would work for me is something like: Although DOM Level 2 continues to be subject to Errata Management Except it's not. As far as I know, errata haven't been published for close to a decade now, and there are no plans to publish any. This in spite of known things that need errata. Or in other words, DOM Level 2 contains text that is known to be wrong and there are no plans to fix that in DOM Level 2. That's the problem people have with treating it as normative, sort of. The rest of your proposed verbiage looks fine, but I guess I don't care that much about the verbiage here. -Boris
Re: Obsolescence notices on old specifications, again
On Tue, 24 Jan 2012, Glenn Adams wrote: On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org wrote: You keep saying this throughout this thread without pointing to specifics. It's impossible to argue with broad, sweeping generalizations like this. So far, you have yet to point to one concrete organization/statute that cares about REC status. Ojan, apparently you are not familiar with international or national standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I could give you a list of hundreds if you wish, all having encoded such rules into their formal processes. I've no problem with providing stale snapshots for use by standards organisations and governments stuck with outdated models. That's fine. Nobody is saying that we should remove DOM2 altogether. Indeed, I've been arguing we should publish snapshots _more often_. I say we take DOM4 right now and publish it as a REC, and then do that every 6 months. That's the best way to serve organisations that need this artificial stability. The point is to make sure that people reading the stale documents know that that is what they are doing. That's why the proposal is merely to have a warning on the stale documents, not remove them altogether. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 1:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/24/12 8:58 PM, Glenn Adams wrote: 2012/1/24 Ojan Vafai o...@chromium.org mailto:o...@chromium.org Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 That doesn't really work for me. What would work for me is something like: Although DOM Level 2 continues to be subject to Errata Management Except it's not. As far as I know, errata haven't been published for close to a decade now, and there are no plans to publish any. This in spite of known things that need errata. As long as the W3C Process Document [1] applies, DOM2 is subject to Errata Management until such a time as it is formally Rescinded. It matters not whether there are any plans to publish errata or not. [1] http://www.w3.org/2005/10/Process-20051014/
Re: Obsolescence notices on old specifications, again
Ian, I agree with the sentiment of your response (take DOM4 right now and publish it as a REC). And, were it not for the W3C Process Document, we might do just that. However, for the time being, we need to work within the process document. The best way to do that is attempt to (as rapidly as possible) obtain consensus on publishing DOM4 as a LC then quickly progress to CR. I personally (and the member I represent) will do whatever I (we) can to assist in that process. And the same applies for the other WIP DOM related specs. On Tue, Jan 24, 2012 at 1:15 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org wrote: You keep saying this throughout this thread without pointing to specifics. It's impossible to argue with broad, sweeping generalizations like this. So far, you have yet to point to one concrete organization/statute that cares about REC status. Ojan, apparently you are not familiar with international or national standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I could give you a list of hundreds if you wish, all having encoded such rules into their formal processes. I've no problem with providing stale snapshots for use by standards organisations and governments stuck with outdated models. That's fine. Nobody is saying that we should remove DOM2 altogether. Indeed, I've been arguing we should publish snapshots _more often_. I say we take DOM4 right now and publish it as a REC, and then do that every 6 months. That's the best way to serve organisations that need this artificial stability. The point is to make sure that people reading the stale documents know that that is what they are doing. That's why the proposal is merely to have a warning on the stale documents, not remove them altogether. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Obsolescence notices on old specifications, again
I think the point that is most important to me to capture is that DOM2 no longer reflects the behavior in many browsers. So how about: DOM2 is no longer updated and doesn't in all cases reflect behavior in popular implementations. DOM4 is the latest actively maintained and updated version. link to DOM4 / Jonas 2012/1/24 Ojan Vafai o...@chromium.org: Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com wrote: I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same as saying DOM2 is a WIP. This is because the former can be read as saying that the normative content of DOM2 is now replaced with DOM4. I'm not sure what you mean by [DOM2] is a work on which progress has stopped. DOM2 is a REC, and is only subject to errata [1] and rescinding [2]. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind I'm not sure where the proposed obsolescence message falls in terms of [1] or [2]. Perhaps you could clarify, since presumably the process document will apply to any proposed change. On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 08:33 PM, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Not at all; it's a work on which progress has stopped long ago.
Re: Obsolescence notices on old specifications, again
On Tue, 24 Jan 2012, Glenn Adams wrote: Ian, I agree with the sentiment of your response (take DOM4 right now and publish it as a REC). And, were it not for the W3C Process Document, we might do just that. However, for the time being, we need to work within the process document. Actually, no, we don't. We're sentient beings, our adherence to bureaucratic protocols is entirely voluntary. But that's besides the point, which was just that we should make it clear to readers of drafts that are out of date that those drafts are no longer the most useful documents available. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Obsolescence notices on old specifications, again
DOM2 was not created for the purpose of reflecting the behavior in popular implementations. So it would be misleading to use this rationale. I would suggest the more neutral language I proposed above: Although DOM Level 2 continues to be subject to Errata Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, it is no longer being actively maintained. Content authors and implementers are encouraged to consider the use of newer formulations of the Document Object Model, including DOM4 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance . I believe this avoids any misreadings and has the intended effect of warning authors/implementers about the status of DOM2 and its newer formulation in progress. On Tue, Jan 24, 2012 at 1:21 PM, Jonas Sicking jo...@sicking.cc wrote: I think the point that is most important to me to capture is that DOM2 no longer reflects the behavior in many browsers. So how about: DOM2 is no longer updated and doesn't in all cases reflect behavior in popular implementations. DOM4 is the latest actively maintained and updated version. link to DOM4 / Jonas 2012/1/24 Ojan Vafai o...@chromium.org: Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com wrote: I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same as saying DOM2 is a WIP. This is because the former can be read as saying that the normative content of DOM2 is now replaced with DOM4. I'm not sure what you mean by [DOM2] is a work on which progress has stopped. DOM2 is a REC, and is only subject to errata [1] and rescinding [2]. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind I'm not sure where the proposed obsolescence message falls in terms of [1] or [2]. Perhaps you could clarify, since presumably the process document will apply to any proposed change. On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 08:33 PM, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Not at all; it's a work on which progress has stopped long ago.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 1:26 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: Ian, I agree with the sentiment of your response (take DOM4 right now and publish it as a REC). And, were it not for the W3C Process Document, we might do just that. However, for the time being, we need to work within the process document. Actually, no, we don't. We're sentient beings, our adherence to bureaucratic protocols is entirely voluntary. Right. And last time I checked this is a W3C mailing list, a W3C group, and W3C documents under discussion. So presumably we sentient beings have at least implicitly signed up to the W3C Process (whether we agree with it or not). Let's not continue to belabor this thread though since, as you say, its beside the point. :)
Re: Obsolescence notices on old specifications, again
* Glenn Adams wrote: That doesn't really work for me. What would work for me is something like: Although DOM Level 2 continues to be subject to Errata Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, it is no longer being actively maintained. Content authors and implementers are encouraged to consider the use of newer formulations of the Document Object Model, including DOM4 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance . The point is to say something along the lines of If this document contains errors, or text that is often misunderstood, do not expect corrections or clarifications to appear here or in the associated errata document, you are more likely to find them $elsewhere. The W3C Process requires Working Groups to keep the errata document up to date and to keep their Recommendations up do date by applying errata to the Recommendations and publishing them through the PER process. That is Errata Management as far as I would understand the term, and the Working Group wishes to convey they won't do so. The document would be subject to Errata Management only in so far as that publishing such a note would not remove the option for the Working Group to change its mind, but that is not useful information for people the note would be addressed to: if the group did change its mind, it can just update the note, new readers would get up to date information, and people who read the note long ago would require a note at $elsewhere to learn about new developments at the old lo- cation. That the Working Group might change its mind they would al- ready know due to the note being there in the first place. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Obsolescence notices on old specifications, again
I object to adding such notice until all of the proposed replacement specs reach REC status. G. On Mon, Jan 23, 2012 at 2:01 AM, Ms2ger ms2...@gmail.com wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/**Public/www-dom/2012JanMar/**0011.htmlhttp://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
Re: Obsolescence notices on old specifications, again
I support adding warnings. As far as I know, all major browser vendors are using the more modern version of each of these specs for implementation work. That's certainly true for WebKit at least. It doesn't help anyone to look at outdated specs considering them to be the latest and greatest when the vast majority of implementations no longer match them. Ojan On Mon, Jan 23, 2012 at 10:06 AM, Glenn Adams gl...@skynav.com wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. On Mon, Jan 23, 2012 at 2:01 AM, Ms2ger ms2...@gmail.com wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/**Public/www-dom/2012JanMar/**0011.htmlhttp://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 12:06 PM, Glenn Adams gl...@skynav.com wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. Why? The real world of modern spec use and authoring is no longer tightly tied to reaching REC (or even CR or PR), and the current situation of outdated specs with no warnings, misleadingly presented as if they represent modern practice, repeatedly leads to both user and implementer confusion. I don't know if this is the right thing to do for all of the listed specs, but in general this is important to fix. -- Glenn Maynard
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 1:01 AM, Ms2ger ms2...@gmail.com wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html I also strongly support adding warnings. There's little worse than spending time reviewing or even implementing a feature from a spec only to be told that it's obsolete, everyone else already knew that, and you just wasted a bunch of time. To answer Glenn's objection, many of the specs already have better and more functional replacements, regardless of their status in the W3C Process. Even if they don't, knowing that we consider a spec to be abandoned and obsolete is valuable - that way people can either work on a replacement, or figure out what was wrong with the original draft that causes us to abandon it and fix that. Omitting such a warning helps literally no one. ~TJ
Re: Obsolescence notices on old specifications, again
I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. G. On Mon, Jan 23, 2012 at 12:09 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Jan 23, 2012 at 12:06 PM, Glenn Adams gl...@skynav.com wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. Why? The real world of modern spec use and authoring is no longer tightly tied to reaching REC (or even CR or PR), and the current situation of outdated specs with no warnings, misleadingly presented as if they represent modern practice, repeatedly leads to both user and implementer confusion. I don't know if this is the right thing to do for all of the listed specs, but in general this is important to fix. -- Glenn Maynard
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 12:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. We have repeated evidence that pretending these specs aren't obsolete and useless hurts web implementors and authors. We're targeting the web with our specs, so that's extremely relevant for us, more so than non-web industries dealing with personal regulatory issues. Ignoring the regulatory issues for a moment, the non-web industries harm themselves (or rather, the down-level authors writing content for the things those industries are producing) by attempting to use these obsolete specs as well, since they'll be producing things that don't match the public web. But really, the important thing is just that these specs are hurting the web, and our primary focus is the web. ~TJ
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 2:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Jan 23, 2012 at 12:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. We have repeated evidence that pretending these specs aren't obsolete and useless hurts web implementors and authors. We're targeting the web with our specs, so that's extremely relevant for us, more so than non-web industries dealing with personal regulatory issues. Ignoring the regulatory issues for a moment, the non-web industries harm themselves (or rather, the down-level authors writing content for the things those industries are producing) by attempting to use these obsolete specs as well, since they'll be producing things that don't match the public web. But really, the important thing is just that these specs are hurting the web, and our primary focus is the web. In my opinion, the poor progress (in terms of time) in obtaining closure on new specs (i.e., reaching REC status) is doing more harm than keeping mature specs on the book. Furthermore, the industry I work in is not something outside the web, but is part of the web. It is just a part of the web that tends to evolve more slowly, and, consequently, assigns more priority to creating and maintaining formally mature specs.
Re: Obsolescence notices on old specifications, again
Tab, Le 23 janv. 2012 à 22:03, Tab Atkins Jr. a écrit : We have repeated evidence that pretending these specs aren't obsolete and useless hurts web implementors and authors. We're targeting the web with our specs, so that's extremely relevant for us, more so than non-web industries dealing with personal regulatory issues. I personally agree that developers need to be directed to the latest spec. Some warning should be there. But a person outside the W3C should not be expected to be taken to some draft document for its implementation. The word obsolete about a spec that has no REC-status replacement really gives outsiders the impression that the whole thing is obsolete (there would be no recommendation of the W3C for my purpose? I thought they did). Another formulation needs to be found, even something such as about to be obsoleted. Ignoring the regulatory issues for a moment, the non-web industries harm themselves (or rather, the down-level authors writing content for the things those industries are producing) by attempting to use these obsolete specs as well, since they'll be producing things that don't match the public web. To my personal taste this feels in line with the craze of running after the latest update all the times. The way Chrome does it without warning you and Firefox screams to update to a new version every other month has the reasons to destabilize people! How can I be sure that my neighbours' website is going to play tomorrow? (he doesn't follow the latest trends yet, he'll learn) A good example of such craze is the Flash player: no RECs here, just one proprietary implementation. Flash upgrades have killed old deployments! Adobe or MacroMedia can't be blamed... no promise was made, no standard was declared to be followed (at least recently). paul
Re: Obsolescence notices on old specifications, again
* Ms2ger wrote: The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. If you want to say more than that the specifications are no longer being maintained and which newer specifications might contain more recent de- finitions for the features covered you will have to create a process for that first (it would require Advisory Committee review for instance, as otherwise you are likely to create unnecessary drama). I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) As far as I am aware, CSSOM is an unmaintained and incomplete set of ideas, and what of it reflects actually implemented behavior and what may change tomorrow is anyone's best guess so that is clearly not a suitable replacement. DOM4 fails to define many widely implemented features and makes many backwards-incompatible changes, I don't see how someone who wants to im- plement the DOM in Java would use the draft rather than the Recommen- dations as a starting point, especially not now as it's rather unclear how much consensus behind all the various proposed changes is outside a rather narrow group of people around the draft's editors. It's a stretch to call it a specification at all, it's more like a reference implemen- tation in an ad-hoc assembly language that's not very useful for people who are not Web browser DOM implementation maintainers. If you want to know if setAttributeNS changes the namespace prefix, you go to the DOM Level 3 Core specification which will tell you If an attribute with the same local name and namespace URI is already present on the element, its prefix is changed ... as the second sentence; you don't go to DOM4 and debug the code there to combine the facts that it sets `prefix` to a certain value in step #4, does not change it in the steps 5-9, and then does not use the value in step ten, into the conclusion that unless you missed some subtlety in the code, or the many definitions it relies on, that it does not change it. And a reviewer is unlikely to even notice the proposal would change the behavior. The proposal pretends that .createElement creates elements in the XHTML namespace. That is not what all current browsers do, it's not what non- browser implementations currently do, and probably not what they should do or are likely to do in the future. So how does that help people who do not already know about DOM4 and would not use DOM Level 2 Core as a reference anyway? For DOM Level 2 HTML the proposed alternative is indeed better at least in some regards like coverage, so a pointer would make some sense. and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation You will have to use the Rescinding process for that, and this would re- quire a legal analysis of the impact of rescinding the Recommendations (Validation does not seem to indicate under which Patent Policy it has been produced, and Load and Save was produced under the transitional rules; under the 2004 Patent Policy rescinding a Recommendation has im- plications on licensing requirements, and it is not clear to me whether people who wish to implement either specification in a year from now to replace some legacy product with backwards-compatibility would be worse off if the documents were rescinded). I also note that you have made no argument why these should be rescinded beyond perhaps that web browser developers might not want to implement it currently if they haven't already done so. That is not something to capture in the status of these documents. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Obsolescence notices on old specifications, again
On Mon, 23 Jan 2012, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. I object to REC status, and support implementing Ms2ger's proposal forthwith. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 5:58 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Ms2ger wrote:I propose that we add a pointer to the contemporary specification to the following specifications: ... * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) ... As far as I am aware, CSSOM is an unmaintained and incomplete set of ideas, and what of it reflects actually implemented behavior and what may change tomorrow is anyone's best guess so that is clearly not a suitable replacement. As an FYI, the two CSSOM specs now have new co-editors, who are working towards publishing new WDs within the next month. On the other hand, this work contains innovations that remain immature and need further implementation activity and testing (as would be required by the normal maturation process in the W3C).
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 11:01 AM, Ms2ger ms2...@gmail.com wrote: I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. I support adding such notices to the above-mentioned specs. On Mon, Jan 23, 2012 at 10:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I think proliferating obsolete stuff is harmful. Which laws or regulations require compliance with some of the above-mentioned specs? Have bugs been filed on those laws and regulations? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
