More on extensibility

In last week's conference call I made a point about the different kinds
of extensibility that we need to address, and how they get lumped
together under the "open content" label. Here are more details.

I see (at least) three kinds of extensibility at work in WSD:

1. Metadata

These are analogous to XML Schema annotations. They are segregated
in special elements (<wsdl:annotation/>?) and classified as intended for
human-consumption only or machine-readable. Machine-readable
metadata is XML (what else?) and always namespace-qualified.
Possible uses of metadata: tool-specific information, programming
language binding information, things such as "parameterOrder", etc.

WSD processors can always safely ignore metadata, so metadata
cannot be "required".

2. Architected Extensions

By these I mean things like binding extensions or message part type
attributes in WSDL 1.1. Our specification will define the exact points
of extensibility and the semantics that such extensions will carry. For
instance, a binding extension must be a binding, and that's it; similarly,
a part type must refer to a "type" as defined by a certain type system.
It cannot be used to specify, say, that a message must include a digital
signature. In WSD we can add more extensions of this kind, such as
the "feature" feature (for lack of a better name; example: a session
"feature", both at the interface and the binding level).

A processor that fails to recognize a binding will automatically fail to
recognize anything that depends on it, for instance an endpoint. Similarly,
if it fails to recognize a part type, and there are no alternatives it recognizes
(assuming for the sake of argument that we define several part types attributes
as being equivalent representations of the same type, which we may well
decided not to do), then it won't recognize the message, hence the operation.
A processor may still decide that it wants to deal with incomplete structures,
e.g. by saying "I don't recognize endpoint A in this service, but I do recognize
endpoint B in the same service, so let's just deal with that one", or "I cannot
make sense of operation 'foo' in this interface, but operation 'bar' is fine".

In other words, the extent of the ignorance of the processor is known to
the processor itself. Again, no need for "required" here. (This is completely
orthogonal to whether, in a SOAP binding extension, we need a way to
mark a header block as required, or to whether an interface or binding should
be able to say that a "feature" is required.)

3. Language Extensions

These extensions can appear pretty much everywhere and are used to extend
the WSD language itself. Rather than having processors run into a new kind
of extension as they go about reading a document, it would be preferable
for this kind of extensions to be declared at the top level. This way,
processors would know about the extension vocabularies used by
a document from the very beginning.

I also think that having a wsd:required attribute marking an entire vocabulary
as required (for a processor to make sense of the document) would be
better than using fine-grained wsdl:required attributes the way WSDL 1.1
does it. A processor that ignores a language extension vocabulary required
by a document simply does not understand the document and should give
up processing at once.

Roberto

--
Roberto Chinnici
Java and XML Software
Sun Microsystems, Inc.

Received on Wednesday, 1 May 2002 23:01:08 UTC