Re: Clarify 'scope' of {element declarations} and {type definitions} re SparqlQuerySimplified-1G

Having discussed this issue with Arthur on the WSDL 2.0 implementors call, I
have changed my thinking on this. As Arthur pointed out, the notion of a
schema component being 'referenceable' is scoped to the WSDL documents that
inline or import the relevant schema, but the notion of documents is not
present in the component model. So we can't say that an ElementDeclaration
or TypeDefinition is referenceable by a WSDL component because in the
component model we cannot make the links between ElementDeclarations,
TypeDefinitions, WSDL components and the documents that they originated
from.

To enforce document-related referenceability in the component model, each
component would need a property that holds the set of schema namespaces that
the component can reference and this could be used to enforce or validate
referenceability of Element Declarations and Type Definitions in the
component model. We agreed this was too big a change for unknown merit.

I'm happy with Arthur's point that referenceability of schema components is
a document-level concept not applicable to the component model and his
suggestion that if a WSDL component was changed to refer to some Element
Declaration or Type Definition that was not referenceable to the underlying
WSDL document, then if the component model is serialized or converted in
some way to a document model an xs:import must be added to the underlying
document for the newly referenced schema namespace.

So that means option 1) from my previous post - the Description's {element
declarations} property contains *all* of the schema elements - but without
the surrounding discussion from that post.

regards,
John Kaputin


On 1/11/07, John Kaputin (gmail) <jakaputin@gmail.com> wrote:
>
> I like Roberto's suggestion that the component model should contain only
> the element declarations and type definitions that are *referenceable* in
> the component model - that is, only those from schemas inlined, or whose
> namespace is imported, within a wsdl:types element in the root description
> or in a wsdl:imported description.
>
> The only assertion that deals with schema referencability is Schema-0016
> but this is a document assertion, not a component model assertion. This can
> be used to validate references to schema components within the WSDL infoset,
> but note that this checks the validity of the reference, not the
> referenceability of the schema components themselves.
>
> Let's suppose Schema-0016 is violated because the 'element' attribute of a
> <wsdl:fault> refers to an element declaration in a schema that is not
> inlined or imported within a wsdl:types element, then let's examine what
> this means for the component model.
>
> 1)  If the Description's {element declarations} property contains *all* of
> the schema elements:
>
> then the InterfaceFault {element declaration} property will resolve to an
> ElementDeclaration, albeit to one that is not referenceable by the WSDL
> 2.0 document. For a read-only use case that parses a WSDL document into a
> component model, an implementation can probably just infer from the
> Schema-0016 violation that there is a problem in the component model (e.g.
> by tying the underlying infoset to the component model, it can map the
> wsdl:fault's element reference error to the InterfaceFault component).  But
> for a component model authoring use case where an InterfaceFault component
> is changed to refer to an ElementDeclaration that is not referenceable, it
> is not clear how to detect this problem because the spec is silent on the
> possibility of non-referenceable ElementDeclarations. The only way to
> re-validate the component model is to go back to the underlying infoset and
> check assertion Schema-0016.
>
> There's a usability problem too - the WSDL author might modify the
> InterfaceFault to refer to an ElementDeclaration that was available in the
> Description's {element declarations} property, only to find out when the
> component model is re-validated that the chosen Element Declaration is not
> referenceable. It might still seem odd to the WSDL author that they are
> offered element declarations that they cannot use.
>
> It might be better if the spec included a boolean property of
> ElementDeclaration indicating whether it is referenceable or some suitable
> component model assertion that an application can use to decide how to
> handle non-referenceable ElementDeclarations (e.g. suppress them or
> display them disabled/greyed-out).
>
> 2) If the Description's {element declarations} property contains only the
> *referenceable* schema elements:
>
> then this eliminates the possibility of modifying a component reference to
> an ElementDeclaration that is not referenceable and it eliminates the need
> for the boolean property or component model assertion described above, but
> it does mean that theInterfaceFault's {element declaration} property will be
> empty if in the infoset the wsdl:fault violated Schema-0016. So the
> InterfaceFault will have a dangling reference and assertion
> QName-resolution-1219000 will be violated.
>
> I prefer option 2).  This applies to {type definitions} too.
>
> regards,
> John Kaputin.
>
>
> On 1/10/07, Roberto Chinnici <Roberto.Chinnici@sun.com > wrote:
> >
> >
> > Arthur,
> >
> > I wasn't arguing that we should keep in the model only *referenced*
> > components. My proposal was to add only *referenceable* components, i.e.
> > all schema components whose namespace is the target of a xs:schema or
> > xs:import element under wsdl:types (in the root WSDL document or in any
> > imported one). There is no pruning step involved in doing so.
> > Referenceable components satisfy the tools requirements you mention
> > quite nicely, because they are precisely the components that you may
> > reference from a WSDL component while authoring a WSDL document. In the
> > case of built-in schema types, since they are always referenceable,
> > they'd never be pruned (there is no pruning).
> >
> > Thanks,
> > Roberto
> >
> > Arthur Ryman wrote:
> > >
> > > Roberto,
> > >
> > > It is simpler to include the components that are encountered when
> > > schemas are parsed. Otherwise you'd have to post process the component
> > > model and prune out unreferenced schema components, even in imported
> > > namespaces.
> > >
> > > Given that you have to parse the schemas as you encounter them, i.e.
> > > to locate referenced components, what is the benefit of the additional
> >
> > > postprocessing step to prune out unreferenced ones?
> > >
> > > Also, for consistency, wouldn't we also have to prune out any of the
> > > unreferenced built-in schema types?
> > >
> > > I can think of good uses for keeping the unreferenced components, e.g.
> > > to assist in authoring. Suppose you want an editor to update a WSDL
> > > 2.0 document. You should be able to reference any visible components
> > > in the imported schema whether or not some other component referenced
> > > them previously. Therefore they should be available in the component
> > > model, i.e. you don't want to have to reparse the imported schemas.
> > > Furthermore, some of the constraints in the spec imply conditions on
> > > the structure of element declarations, e.g. the IRI style. So even
> > > though WSDL components don't directly reference some types, the
> > > constrains refer to the structure and therefore reference them
> > > indirectly. e.g. the type of child elements or an input message.
> > >
> > > It would also be expensive to validate the component model, since for
> > > each element or type component, you'd have to scan the component model
> >
> > > for a reference to it (like a gc mark and sweep).
> > >
> > > 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
> > >
> > >
> > > *Roberto Chinnici <Roberto.Chinnici@Sun.COM>*
> > > Sent by: www-ws-desc-request@w3.org
> > >
> > > 01/10/2007 12:53 PM
> > >
> > >
> > > To
> > >       Arthur Ryman/Toronto/IBM@IBMCA
> > > cc
> > >       Jonathan Marsh < jonathan@wso2.com>, "'John Kaputin'"
> > > <KAPUTIN@uk.ibm.com>, woden-dev@ws.apache.org, www-ws-desc@w3.org,
> > > www-ws-desc-request@w3.org
> > > Subject
> > >       Re: Clarify 'scope' of {element declarations} and {type
> > definitions}
> > > re SparqlQuerySimplified-1G
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > This should be a new issue. I'm not convinced by the arguments in this
> > > thread.
> > >
> > > I find the argument by analogy with XML Schema unconvincing. When it
> > > comes to WSDL importing/including WSDL, it's fine to base our approach
> >
> > > on the schema importing/including schema case, but the WSDL importing
> > > schema scenario is qualitatively different, since we're talking of
> > > cross-description-language importing.
> > >
> > > Given that we are defining the WSDL spec, not the XML Schema spec, we
> > > don't need to bother with validity of the component model at the
> > schema
> > > level. So schema components that are not referenceable by WSDL
> > > components need not appear in the WSDL component model, because they
> > > don't affect WSDL validity per se.
> > >
> > > This is the case of components defined by a schema S1 imported by a
> > > schema S2 which is in turn imported by WSDL document W. It's only if W
> > > imports S1 that those components need to appear in the component
> > model.
> > >
> > > This approach also makes the rules in 2.17 of part 1 [1] stronger,
> > > because the {element declarations} and {type definitions} sets will
> > then
> > > be of minimal size (= they will not contain any components that are
> > not
> > > referenceable). This seems a desirable property for an interchange
> > > format too: to contain all elements/types which could ever be used,
> > but
> > > not more.
> > >
> > > [1]
> > >
> > http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#qnameres<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#qnameres>
> > >
> > > Thanks,
> > > Roberto
> > >
> > > Arthur Ryman wrote:
> > > >
> > > > ++1
> > > >
> > > > Also, WSDL 2.0 works that way. If A.wsdl imports namespace B then
> > any
> > > > components in B's component model are also in A's, otherwise you'd
> > get
> > > > dangling component references.
> > > >
> > > > 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
> > > >
> > > >
> > > > *"Jonathan Marsh" <jonathan@wso2.com >*
> > > > Sent by: www-ws-desc-request@w3.org
> > > >
> > > > 01/09/2007 05:31 PM
> > > >
> > > >
> > > > To
> > > > Arthur Ryman/Toronto/IBM@IBMCA, < woden-dev@ws.apache.org >
> > > > cc
> > > > "'John Kaputin'" <KAPUTIN@uk.ibm.com>, < woden-dev@ws.apache.org>,
> > > > <www-ws-desc@w3.org>
> > > > Subject
> > > > RE: Clarify 'scope' of {element declarations} and {type definitions}
> >
> > > > re SparqlQuerySimplified-1G
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > +1. The visibility of imported components for the purpose of
> > resolving
> > > > QName references is a separate matter than the presence of imported
> > > > components in the component model. Not very obvious, but AIUI that's
> > > > the way schema works and we're following down that path for better
> > or
> > > > worse.
> > > >
> > > > *Jonathan Marsh* - http://www.wso2.com < http://www.wso2.com/> -
> > > > http://auburnmarshes.spaces.live.com
> > > > <http://auburnmarshes.spaces.live.com/>
> > > >
> > > >
> > > > *From:* www-ws-desc-request@w3.org [mailto:
> > www-ws-desc-request@w3.org]
> > > > *On Behalf Of *Arthur Ryman*
> > > > Sent:* Tuesday, January 09, 2007 12:53 PM*
> > > > To:* woden-dev@ws.apache.org *
> > > > Cc:* John Kaputin; woden-dev@ws.apache.org; www-ws-desc@w3.org*
> > > > Subject:* Re: Clarify 'scope' of {element declarations} and {type
> > > > definitions} re SparqlQuerySimplified-1G
> > > >
> > > >
> > > > John,
> > > >
> > > > As we discussed on the Woden telecon, the component model should
> > > > create ElementDeclaration and TypeDefinition components for all the
> > > > element and type definitions that are contained in any schema
> > > > (inlined, imported, or included).
> > > >
> > > > 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
> > > >
> > > > *"John Kaputin (gmail)" < jakaputin@gmail.com>*
> > > >
> > > > 01/09/2007 08:02 AM
> > > >
> > > >
> > > > Please respond to
> > > > woden-dev@ws.apache.org
> > > >
> > > >
> > > >
> > > > To
> > > > www-ws-desc@w3.org
> > > > cc
> > > > woden-dev@ws.apache.org, "John Kaputin" < KAPUTIN@uk.ibm.com>
> > > > Subject
> > > > Clarify 'scope' of {element declarations} and {type definitions} re
> > > > SparqlQuerySimplified-1G
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I would like clarification the WSDL 2.0 testcase
> > > > SparqlQuerySimplified-1G and which schema element declarations
> > should
> > > > be present in the {element declarations} property of the Description
> > > > component. I think I had a conversation about this issue with
> > Jonathan
> > > > and Arthur driving out to Niagra Falls at the July interop.
> > > >
> > > > The baseline component model interchange format for this testcase
> > > > includes an element declaration whose namespace is not inlined or
> > > > imported within the WSDL document's <types> element.
> > > >
> > > > Baseline sparql-protocol-query.canonical.wsdlcm contains this item:
> > > >
> > > > <elementDeclarationComponent xml:id="c22">
> > > > <name>
> > > > <base:namespaceName> http://www.w3.org/1999/02/22-rdf-syntax-ns#
> > > > < http://www.w3.org/1999/02/22-rdf-syntax-ns> </base:namespaceName>
> > > > <base:localName>RDF</base:localName>
> > > > </name>
> > > > <system> http://www.w3.org/2001/XMLSchema
> > > > < http://www.w3.org/2001/XMLSchema> </system>
> > > > </elementDeclarationComponent>
> > > >
> > > > This element declaration is defined in a schema which is imported by
> > > > the <xs:schema> element inlined within the <types> element of
> > > > sparql-protocol-query.wsdl. However, the namespace
> > > > http://www.w3.org/1999/02/22-rdf-syntax-ns#
> > > > < http://www.w3.org/1999/02/22-rdf-syntax-ns> is not xs:imported
> > > > directly within the <types> element.
> > > >
> > > > According to Part 1, section 3.1 Using W3C XML Schema Description
> > > > Language:
> > > > Schema-0016 "A WSDL 2.0 document MUST NOT refer to XML Schema
> > > > components in a given namespace unless an xs:import or xs:schema
> > > > element information item for that namespace is present ..."
> > > >
> > > > In implementing Woden, I interpreted this to mean that {element
> > > > declarations} and {type definitions} only contain schema components
> > > > whose namespace is inlined or imported directly within the <types>
> > > > element. The Woden sparql-protocol-query.canonical.wsdlcm file
> > refects
> > > > this, in that the element declaration mentioned above is not present
> > > > (and Woden is failing the testcase accordingly).
> > > >
> > > > However, it may be that the intention of the WSDL 2.0 authors is
> > that
> > > > ALL global element declarations and type definitions referenceable
> > by
> > > > XML Schema MUST be included in {element declarations} and {type
> > > > definitions}, regardless of whether they are inlined or imported
> > > > directly within <types> or whether they are 'nested' imports within
> > > > those directly inlined or imported schemas, and that assertions like
> >
> > > > Schema-0016 only apply when WSDL 2.0 components like InterfaceFault
> > > > and InterfaceMessageReference resolve their 'element' QNames to
> > > > ElementDeclarations (but not to the contents of {element
> > declarations}
> > > > and {type definitions} themselves).
> > > >
> > > > Can someone from the working group please explain which
> > interpretation
> > > > is correct?
> > > >
> > > > Thanks,
> > > > John Kaputin
> > > >
> > >
> > >
> > >
> >
> >
> >
>