- From: Michael J Hannah <mjhanna@sandia.gov>
- Date: Tue, 1 Aug 1995 15:32:41 +0700
- To: www-html@w3.org
There is some concern over my proposal to "deprecate" existing list mechanism elements. More than one individual has expressed concern that this will "break existing documents" a concern that I do not understand. Identifying something as "deprecated" should not break anything. I am basing my definition of this term "deprecate" on previous work in standards groups. My understanding is that "deprecate" is only phase one, where "obsolete" is phase two, and this second phase _may_never_ _come_. My (non-legalese) definition of this "deprecate" phase is: "document writers should no longer use this, the standard should not propose any changes to this, but browsers should continue to accept this." The idea is to have such a better new way to do things that people stop using the old (deprecated) way for all newly created documents, and the language group stops tinkering with the old way in the standard, but focuses efforts on the new (supposedly) better way. Since I believe that my proposal for LIST is a better way (IMHO ;-) I feel sure that the usage of these old list constructs will simply fade away, but existing documents that use them will still be renderable by browsers. When (or even if) an element is identified as "obsolete", then it is possible for newer browsers to not recognize it (though I would still expect most vendors to continue to handle any construct that had a significant installed base of documents using it) Only when (or even if) an element is made "obsolete" would I also expect conversion tools to input (version old) documents and produce (version new) documents. This is what happens for most any other language I have every dealt with, from computer languages like FORTRAN, to document languages like FrameMaker or WordPerfect. But I would not expect a construct to be declared "obsolete" until a (better) replacement construct was available and in use. With this definition of the term, I do not understand the concern of "breaking" existing documents. If the concerns are valid, then _NO_ construct in the language that was at all widely used could _ever_ be deprecated. Am I missing something? Michael Hannah
Received on Tuesday, 1 August 1995 17:32:23 UTC