- From: Lofton Henderson <lofton@rockynet.com>
- Date: Wed, 07 Aug 2002 06:52:33 -0600
- To: www-qa-wg@w3.org
At 05:51 PM 8/6/02 +0100, you wrote: >On 2002.08.06 17:06 Dominique Hazaël-Massieux wrote: >>Le mar 06/08/2002 à 17:52, Andrew Thackrah a écrit : >[...] >>> Also I currently regard profiles to be a form of product >>>categorization >>> rather than an aid to technical specification. >>One of the goals of the QA Framework is to promote interoperability, >>which is one of the big gain from standardization. If you just say "up >>to the vendors to use this or this module", what will you say to the >>content producers? > > If I was a spec author I would say nothing! because it is outside my brief > to speculate on products. I would want to concentrate on capturing > technical requirements only. Two comments: 1.) it is pretty explicit in the QA Activity statement, the QAWG Charter, and QA Framework Introduction that W3C thinks (collectively at least) that the WGs are responsible for the success of their standard in the field, not just for inventing superior technologies. 2.) I don't believe that publishing a technical spec and leaving the interoperability (between producers and consumers) to the marketplace works (at least not reliably). I've had direct contrary experience, in which we had to go back after several years, add a "Rules for Profiles", define a couple of target profiles, and try to deal with a half-decade of ugly legacy content and implementations. > If I was a marketing person I would say to the content producers that > it is in their interests to ensure that a relevent component exists for the > target application. E.g. I currently have a nice SVG plug-in for my Mozilla > browser, I'm not sure that I'd point to HTML-with-graphics as an example of successful interoperability. There are people (e.g., me) making SVG content that that SVG plugin cannot handle, and the plugin maker's authoring tool is making SVG content that other viewers can't handle. And, of course, the interoperability history of HTML is legendary (and a principal motivation behind XHTML, modularization, and XTHML profiling). >and my apache HTTP server is almost 100% plug-in modules. >These are examples of product developers and content producers working > together in their mutual interest to make new technologies succeed > without being forced to adopt a product profile from outside of their > development strategy. I can't imagine a successful (interoperable) mobile-phone application subset of SVG emerging spontaneously out of industry (content producers and product developers). The original SVG team, re-chartered, and with a lot of new "mobile" vendors on board in the WG, have been spending a good bit of the last year trying to get it right for Mobile (it's at CR now). > I agree that profiles are an important indicator of interoperability. > However > I'm not convinced that interop concerns should be dealt with at the > technical > spec level -I think it comes at a higher level when specs are being > implemented for real. At the very least, the writers of the spec need to provide a specification suitable for profiling and framework for profiling (assuming that profile is appropriate for the particular technology.) It is possible to imagine all or some of the actual profiles being written elsewhere than in the WG, and at a different time. On the other hand, if the requirements are known during the WGs life (e.g., SVG mobile), and if the right players are there (e.g., all the key mobile-device makers), why not do it then and there? I am *not* a believer in letting the industry sort it out after the fact. "When the specs are being implemented for real" is likely to be too late. For example, "browser wars". Maybe there are successful counter-examples, from my experience it sure looks like high risk. You seem to have done a lot of work with HTTP. Does HTTP represent a counter-example where it -- letting industry sort interoperability out after the publication -- has worked well? -Lofton.
Received on Wednesday, 7 August 2002 08:54:48 UTC