RE: A note on the challenge presented by open content models

+1 to Gudge's suggestion of abstract element and substitution group
for extensibility elements, especially those which are essentially 
required
such as the binding.

I think that this would work quite effectively. At the very least, it 
ensures that
you can schema validate what can go where.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Gudge wrote on 10/17/2002 01:52:31 PM:

> 
> With the WSDL schema we could define an abstract globel element decl for
> each location and tell people to put their extensibility element in the
> substitution group for the element that corresponds to the location they
> want to 'extend' in. I need to think about how that would work for
> extensibility elements that need to appear in multiple places ( not sure
> if we have a use case for that )
> 
> Gudge
> 
> 
> 
> > -----Original Message-----
> > From: Amelia A Lewis [mailto:alewis@tibco.com] 
> > Sent: 17 October 2002 10:34
> > To: WS-Desc WG (Public)
> > Subject: A note on the challenge presented by open content models
> > 
> > 
> > 
> > As a result of discussions during today's teleconference, and 
> > related work for support of features and the like, it occurs 
> > to me that existing schema models and languages are not 
> > terribly well-adapted to open content models.  I thought that 
> > I would share these thoughts (lucky you!).
> > 
> > At issue is the fact that there is, at least conceptually, a 
> > schema for WSDL.  It has an open content model, which can be 
> > represented in W3C XML Schema as any, namespace ##other. 
> > This is true for almost all elements in WSDL.
> > 
> > Particular extensions, as a rule, define a sort of 
> > micro-vocabulary intended for use within the context of given 
> > extensibility elements in WSDL.  That is, the elements and 
> > attributes defined for a DIME binding (for instance) would 
> > have particular constraints.  Some should appear as children 
> > of wsdl:binding, others as children of wsdl:operation, others 
> > as children of wsdl:input, wsdl:output, or wsdl:fault.  There 
> > might also be elements or attributes intended to decorate 
> > wsdl:service or wsdl:port.
> > 
> > But there is no way, so far as I know, in any schema 
> > language, to express the required *parent* of an 
> > extensibility element.  It's an interesting omission, once 
> > one considers it.  A deliberately open content model, in 
> > which the extension specifications constrain themselves (in 
> > effect) is not contemplated, and not supported (admittedly, 
> > formalizing such a thing carries some interesting security issues).
> > 
> > This is not an issue for resolution, just for its 
> > thought-provoking qualities.  It appears that the path being 
> > traveled by WSDL (an open content model for the base schema, 
> > with extensions expected to specify their preferred or 
> > required inclusion locations) is not well known.  It may 
> > present obstacles in terms of defining schemas for such extensions.
> > 
> > Amy!
> > -- 
> > Amelia A. Lewis
> > Architect, TIBCO/Extensibility, Inc.
> > alewis@tibco.com
> > 
> > 
>