Extensions and profiles

Hi all,

it seems that there is an opinion among the WG members that standards
shouldn't contain extensions because extensions cause profiling and that
is bad.

Here's how I see it:

     1. A standard (a normative text) is good for interoperability
        because there is an expectation that if somebody else is doing
        similar stuff, they will use the standard instead of reinventing
        it differently.
     2. Standards may contain extensibility points and AFAICS everybody
        agrees that is good practice because the standard can be used
        even if it doesn't cover everything someone needs.
     3. Standard specifications of extensions are good because again, if
        somebody does the same thing that requires extending the base
        standard, they will likely use the standard extensions. In other
        words, a standard extension is a standard, see point one.

There is a great space for profiling when a standard is open for
interpretation on some points - the profile chooses the preferred
interpretation (BP and SOAP/1.1, WSDL 1.1). There's also a space for
profiling when a standard extension is flawed - the profile defines
another extension that replaces the flawed one or the profile just says
the extension should not be used (BP and SOAP/1.1 section 5 Encoding).

To be concrete, that's why optional HTTP binding and optional RPC
operation style are both good, even though not required. If we don't do
a good job of specifying these extensions, somebody will have to create
a profile. They will be able to do so without having to create WSDL 2.1.

We shouldn't make things mandatory just so that somebody cannot fix them
separately in a profile if we screw up.

Best regards,

                   Jacek Kopecky

                   Systinet Corporation

Received on Thursday, 30 October 2003 13:01:10 UTC