W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2007

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

From: Jonathan Marsh <jonathan@wso2.com>
Date: Tue, 23 Jan 2007 17:12:34 +0530
To: "'John Kaputin \(gmail\)'" <jakaputin@gmail.com>
Cc: "'Arthur Ryman'" <ryman@ca.ibm.com>, "'Roberto Chinnici'" <Roberto.Chinnici@sun.com>, "'John Kaputin'" <KAPUTIN@uk.ibm.com>, <woden-dev@ws.apache.org>, <www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
Message-ID: <00fe01c73ee3$99cf33a0$d901640a@DELLICIOUS>
I added this as CR145.  First substantial item on this week's agenda.

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

  _____  

From: John Kaputin (gmail) [mailto:jakaputin@gmail.com] 
Sent: Tuesday, January 23, 2007 4:28 PM
To: Jonathan Marsh
Cc: Arthur Ryman; Roberto Chinnici; John Kaputin; 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

 

Jonathan,
as requested at the end of last weeks WG telecon, I like to see this issue
concluded. It may require a new CR issue. The mailing list discussion tailed
off, but I don't think there was any consensus reached. I think the spec
needs to clearly reflect whatever consensus is reached, with regards to
which schema components from the WSDL documents get represented as Element
Declarations and Type Definitions in the component model. The previous
debate was about all schema components accessible within the XML versus only
those that are *referenceable* in the WSDL as a result of inlining or
importing, and with the latter case there were issues about how the
document-level concept of referenceability applies to the component model.

The only section in the spec that seems to address this issue is:


3.1.3 References to Element Declarations and Type Definitions


but this does not clarify the issues of that discussion.

thanks,
John Kaputin

On 1/12/07, Jonathan Marsh <jonathan@wso2.com> wrote:

Roberto wrote:

Having to choose then, I'd rather go with the smaller component model, 
especially since the difference has a visible impact on the interchange 
format. A related question would be: if a tool didn't include in the 
component model a component that is not referenceable (by my definition, 
i.e there is no xs:import or xs:schema for its namespace), is it broken? 

 

Arthur wrote:

Jonathan and I think it is broken. We are trying to be precise so we can
easily compare component model interchange format results.

 

Specifically, Woden and wsdl-xslt currently agree on the results (except in
the few cases John is trying to fix.)  I don't have a strong position on
this issue, but I do see the appeal of minimizing the set of components we
have to agree on.  Conceptually, there isn't much difference between
skipping the component-model-glue for an element declaration that's buried
deep within schema imports (and thus is unreferenceable), and something like
an attribute declaration which isn't referenceable from WSDL simply because
there's no need for such a reference.

 

I think it would make a document-centric implementation like wsdl-xslt
easier, although I can equally see that it might complicate
component-centric implementations, which are likely to be dominant in
practice.  By document-centric I mean I never consider the existence of a
schema component separate from whether it came from an import.

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com 

 

  _____  

From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Friday, January 12, 2007 12:53 PM
To: Roberto Chinnici
Cc: Jonathan Marsh; 'John Kaputin'; Roberto.Chinnici@Sun.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

 


Roberto, 

See my responses below: 

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: Roberto.Chinnici@Sun.COM 

01/12/2007 02:54 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

 


 

 




Arthur,

I don't understand the classpath analogy. By your argument, shouldn't 
the "classpath" include all schemas that the tool has knowledge of, e.g. 
all those in a repository, including those that have not been imported 
by any document yet? Surely this way the tool would be able to maximally 
help the user. IMO, this makes the alternative proposal just as 
deficient for authoring. 

The WSDL document implicitly defines its schema universe via <xs:schema> and
<xs:import> in <wsdl:types>. These seem the likeliest candidates for
reference so it makes sense to provide these as suggestions for code
complement. A tool should let a user explicitly add more <xs:import> and
<xs:schema> elements to the <wsdl:types>. Of course, the behavior of the
tool is beyond the scope of the spec. I'm just suggesting that this is one
use that could be made of the element and type definitions encountered
during the parsing. 

I'd also like to question the idea that by carrying over into the WSDL 
component models all these schema components which are not referenceable 
you somehow make it possible to run the tools solely off the WSDL 
component model. XML Schema defines six separate namespaces, and correct 
schema processing requires all of them, yet WSDL has properties for just 
two of them: elements and types. So a tool will have to carry around 
additional schema components (model groups, attribute groups, etc.). So 
even in your proposal, the component model is not complete by any means. 

Only type and element components are referenced by WSDL. I would expect a
WSDL editor to integrate with a schema editor to author inline schemas.

Having to choose then, I'd rather go with the smaller component model, 
especially since the difference has a visible impact on the interchange 
format. A related question would be: if a tool didn't include in the 
component model a component that is not referenceable (by my definition, 
i.e there is no xs:import or xs:schema for its namespace), is it broken? 

Jonathan and I think it is broken. We are trying to be precise so we can
easily compare component model interchange format results. 

If yes, how, given that the absence of that component is not internally 
detectable (i.e. there is no WSDL constraint on components that is 
violated)? Compare this case to a tool "dropping" an interface component 
for which there is a binding. 

It's broken because the results don't match the expected results, not
because an assertion is violated. For example, we also check that the other
top level WSDL components are present even if they are not referenced. They
,ust be present because they are contained in the <description> element.

On a somewhat separate note, I'm starting to feel uneasy about 
referenceability being tied to the document a component is defined in. 
Wouldn't this call for documents to be reified in the component model? 

Referenceability is not enforced by the component model. It is just a
document level constraint. If we wanted to capture referenceability then we
would have to model documents and imports in the component model, which we
don't at the moment. 

Otherwise, it seems to me, tools are effectively required to carry 
additional metadata to be able to enforce visibility rules. Would any 
implementor care to comment on this issue? 

As an implementor myself, my attitude is that since I took the cycles to
parse the document and create the components, I might as well keep them.
However, as you point out, I could recover a little memory if I am willing
to do a little extra processing. 

Of course, we really just need to make the spec precise. I am OK either way.
I never really appreciate the logic behind xs:import or wsdl:import anyway.
At least in Java you can abbreviate the reference to a class if you import
it.

Thanks,
Roberto

Arthur Ryman wrote:
> 
> Roberto,
> 
> OK. That closes the gap somewhat. However, you would still have to scan 
> the document to prune out the unreferencable ones.
> 
> The concept of referenceability is relative to the document though. A 
> component might be referenceable from one document but not another, so 
> this requires a post-processing step.
> 
> The way I see tools using the component model is that they help users 
> edit documents. So suppose you are defining an operation and want to 
> reference an element that was seen already from another document but not 
> the current document. e.g. maybe the element was imported by another 
> schema to it is known to the parser when technically unreferenceable 
> because you didn't import at the top level. If the element is in the 
> component model, then a tool could offer it as a choice, and if the user 
> selected it, then insert the import statement.
> 
> This is actually how Java code assist works. If a class in on the 
> classpath then an editor can to code completion on the class name and 
> insert an import in the code. By analogy, the set of seen components is 
> like an implicit "classpath" for WSDL.
> 
> To summarise, your suggestion:
> 1) does require some post-processing to eliminate the unreferenciable 
> components
> 2) may be less conducive to some authoring use cases
> 
> 
> 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 04:36 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
> 
> 
>                  
> 
> 
> 
> 
> 
> 
> 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?con
tent-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>, <
<mailto:woden-dev@ws.apache.org>  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://www.wso2.com/> > -
>  > > http://auburnmarshes.spaces.live.com
>  > > <http://auburnmarshes.spaces.live.com/>
>  > >
>  > >
>  > > *From:* www-ws-desc-request@w3.org [mailto:
<mailto:www-ws-desc-request@w3.org>  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> 
>  > > <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>  
>  > > <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

 
Received on Tuesday, 23 January 2007 12:09:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:45 GMT