- From: Karl Dubost <karl@w3.org>
- Date: Tue, 13 Jul 2004 20:46:13 -0400
- To: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Cc: www-qa@w3.org
- Message-Id: <34AC5AAA-D52F-11D8-B69B-000A95718F82@w3.org>
Hi Al, Le 13 juil. 2004, à 13:31, Al Gilman a écrit : > Was there any discussion as to why the processing policy during > phase-out, to wit: > > - emitters, being strict, should not emit > - acceptors, being loose, should accept > > wound up not included in this definition? Because it's not as simple. You have to think in terms of any kind of technologies first, so it means XHTML, CSS, but also XSLT, XKMS, SOAP, XHTML Modularization etc... many different beasts. -> A product is not only a software. A product can be for example, in the case of XHTML Modularization, a DTD. XHTML Mod is a technology which is used to create other languages. These other languages are emitters or acceptors? You can have authoring tools, libraries, I guess that you classify as emitters. And user agents that you classify as acceptors. But again it's not as simple, even in the case of an authoring tool. Example A deprecated feature in a HTML 4.01 Transitional Document. I open it with my authoring tool (which means I accept it) so it's ok, I have the right to be loose. I change a typo in my text. I save the document... The authoring tool is an emitter... ooops, what is the scenario. - I scrap the deprecated feature? - I warn the users? - I change the doctype? - I do nothing? As you see the behaviour of different of classes of products is not related to the obsolescence and deprecation but to the Conformance and the way you define the behaviour with regard to each other technology. And it's in SpecGL Lite !!! ;) See http://lists.w3.org/Archives/Public/www-qa-wg/2004Jun/0086 -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Received on Tuesday, 13 July 2004 20:54:58 UTC