profiles or not [was Re: Modules and levels in a specification]

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