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

Received on Wednesday, 7 December 2005 21:03:49 UTC