Re: Do <import> and <include> support extensibility elements?

Amy,

The truth is that WSDL 2.0 does not really place much restriction on any 
extension. You may recall that I once proposed imposing some simple 
structure, like "extension property names MUST be QNames", but got shot 
down.

At the moment, it is completely up to the extension author to define its 
semantics and ensure that it hangs together with the rest of the specs. If 
someone defines a terrible extension, no one else will support it. 

The predefined binding extensions are pretty tame and let's hope that 
other extension authors will use them as models of Best Practice.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



Amelia A Lewis <alewis@tibco.com> 
Sent by: www-ws-desc-request@w3.org
12/07/2005 04:00 PM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
www-ws-desc@w3.org
Subject
Re: Do <import> and <include> support extensibility elements?







Hmmm.

On Wed, 7 Dec 2005 15:23:07 -0500
Arthur Ryman <ryman@ca.ibm.com> wrote:
>There is no requirement that an extension element directly affect the 
>component model. Some extension elements could just affect how the 
>component model is created, e.g. like <import> and <include> do
>already.

How is this "not directly affecting" the component model?

I find myself a little uncomfortable with extensible import/include.
Right now, we have a "types" element, which is not a component, but it
acts as a container for element declaration and type definition
components.  We have no "schema" components; we treat schema element
declarations and type definitions as components.

Now, what happens if there is an extension that defines a "component"
in the <types> element information item?  What is its scope?  Does it
define that itself?  Can it, for instance, claim to apply to *only*
those element declaration and type definition components which are *in
this types element information item*?

Because import and include are up a level, they provide still more
potential for problems, although they also point out some existing
potential problems.

A WSDL component model has a *single* description component.  During
import/include, all of the components defined in imported/included
descriptions are, presumably, more or less "promoted" into the
containing WSDL.  Is that right?  We know how to do this for interface,
binding, and service: those are straightforward.

But ... suppose one WSDL has some form of assertion at the description
level ("construct components with a left-handed monkey-wrench") and
another WSDL has a contrary assertion ("components must not be
constructed by left-handed wenches, even if they're monkeys")[1].  That
is, these extensions are defined as immediate children of the
description component in their respective WSDLs, and are scoped to
influence something in the construction of all components in the
containing description.

So, left-handed monkeys import no-left-handed wenches.  What now?
*What is the scope* of these extensions?

Are extensions scoped by syntax (containing element information item)?
Or are they scoped by components (containing component)?  Is there a
difference in how this works between an include and an import?

We already dealt with this once, I think (the question of extension
scope), but was that only for the simple case, a single description
element information item with no imports/includes?

My concern here is one of predictability.  Suppose that we have the
left-handed monkey-wrench directive.  If it appears only in the
imported WSDL, does it apply only to the description element
information item in the imported WSDL, or to both that one and its
parent?  Itself, its parent, and all of its siblings?  What about
children of its siblings?  If an import can have an effect on its
parent in this fashion, is this recursive?

Depending on how implementors answer these questions, you get different
results.

Now, I'll grant you that this is not directly related to the issue of
extensibility of import/include EIIs[2], since the problem exists
without import/include EIIs being extensible, due to the extensibility
of the description component (when is a component not a component?
when it's an imported or included description element information
item).  The reverse is equally problematic, though.

That is, what should the scope of a left-handed monkey-wench directive
be, if it's "inside" an import element information item?  Just that
import?  Its parent WSDL?  Its parent and all siblings?

If an extension element information item *does* define an extension
component, how many levels of "promotion" can there be?  An extension
component defined inside a types element information item, an import,
or an include presumably has, as a parent, its containing description
component ... unless that description component doesn't exist, in which
case ....  Well, a component defined inside an import element
information item *could* be (by executive fiat) declared to have as its
parent the description component which is imported.  Oh, wait.  There
isn't one.

Uh.  I find that I have some questions about extensibility ... or
perhaps, more accurately, about the interaction of extensibility
defined in terms of the infoset and our component model.

[1] Uh.  Sorry.  You didn't really expect me to write this many
paragraphs with a *straight face*, did you?

[2] You know, EIIs that don't define WSDL components could be
designated differently.  For instance, Extended Internal Element
Information Objects (EIEIO)[3].

[3] Ow!  Ow!  I'm *sorry*!  *Moooom*!

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com