Further discussion from James.
Arthur Ryman,
Rational Desktop Tools Development
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
intranet: http://labweb.torolab.ibm.com/DRY6/
----- Forwarded by Arthur Ryman/Toronto/IBM on 07/19/2005 10:27 AM -----
"RDBMS" <RDBMS@aol.com>
07/13/2005 12:38 PM
Please respond to
"RDBMS"
To
Arthur Ryman/Toronto/IBM@IBMCA
cc
"Booth, David \(HP Software - Boston\)" <dbooth@hp.com>
Subject
Re: Question re: WSDL 2.0 and (schema) xs:import
Hi Again Arthur,
Again, thank you for your patience. This is a very important topic.
Hopefully, my examples will make some sense.
The following includes a set of highly abbreviated and abstract set of
schema fragments (representing an assembled schema/sub-schema hierarchy),
and the same .
XML Schema (assembled hierarchy of 3 schemas using 3 separate xs:imports)
Schema A imports Schema B
Schema B imports Schema C
Schema C imports Schema D
A (xs:import "SchemaB" - note that imports found in the lower level
imported/assembled sub-schemas below are NOT duplicated here)
|
B (xs:import "SchemaC")
|
C (xs:import "SchemeD")
|
D
With this example hierarchy and cascading imports, I can reference, bind
to, and validate using the highest level schema (SchemaA.xsd). I do not
need to specifically declare (re-declare) each of the lower level imports
from the sub-schemas that make up my hierarchy.
This type of example for XML Schemas presents a tremendous opportunity for
schema/sub-schema reuse by extension. I can create schemas that are
really nothing more than assemblies of highly modular and standardized
sub-schemas (data structures, data standards, common type libraries,
etc.).
If I elect to reuse an entire hierarchy or part of a hierarchy, I do NOT
need to identify and re-declare all of the lower level xs:imports that
represent the sub-schemas and cascade the hierarchy from that level on
down. My interpretation of WSDL 2.0 is that I would have to do this. I
would need to:
1) interrogate each lower level schema
2) look to see what it imports (note that my example in this note is very
simple and pretty much vertical this could potentially be many imports
within each and fanning out horizontally as well)
3) re-declare all of those same xs:imports from below and across the
entire schema hierarchy within my WSDL <types/>, even though they already
exist, are supported by XML Schemas, and are resolved by my validating
parser for me
In addition to all the manual work this creates and that XML Schemas does
this for me already, future changes to the schema hierarchy at lower
levels where my schema imports are already managed, would introduce a
manual maintenance nightmare and potential for anomaly with WSDL. The
reason is that with any change to a lower level import, I would need to
identify that import and modify/change/delete/augment with additional and
redundant entries in the WSDL <types/>
------------------------------------------------------------------------
Schema A.xsd (this is a standalone schema artifact - xsd file)
<xs:schema
targetNamespace="SchemaA.com"
xmlns:A="SchemaA.com"
xmlns:B="SchemaB.com"
xmlns:C="SchemaC.com"
xmlns:D="SchemaD.com"> Note that I do NOT have to declare these
namespaces if I do not specifically reference a qualified declaration from
the other schemas
<xs:import namespace="SchemaB.com" schemaLocation="SchemaB.xsd"/> Note
that I do NOT declare the cascading imports found in the other schemas
below
more declarations here....
</xs:schema>
=================================================
Schema B.xsd (this is another standalone schema artifact - xsd file)
<xs:schema
targetNamespace="SchemaB.com"
xmlns:B="SchemaB.com">
<xs:import namespace="SchemaA.com" schemaLocation="SchemaC.xsd"/>
more declarations here....
</xs:schema>
=================================================
Schema C.xsd (this is another standalone schema artifact - XSD file)
<xs:schema
targetNamespace="SchemaC.com"
xmlns:C="SchemaC.com">
<xs:import namespace="SchemaC.xsd" schemaLocation="SchemaD.xsd"/>
more declarations here....
</xs:schema>
=================================================
Schema D.xsd (the final and lowest level of the schema hierarchy, again a
standalone artifact - XSD file)
<xs:schema
targetNamespace="SchemaD.com"
xmlns:D="SchemaD.com">
more declarations here....
</xs:schema>
========================================
WSDL 2.0... (as I currently understand the draft recommendation)
In this case and even though the hierarchy is represented within my
schemas by schema xs:imports, I cannot xs:import the highest level schema
(SchemaA.xsd) and let my WSDL parser resolve the intrinsic imports of the
schema hierarchy from there (note that by example above, XML Schemas and
validating parsers do this for me).
<wsdl>
<definitions/>
<types>
<xs:schema
targetNamespace="SchemaA.com"
xmlns:A="SchemaA.com"
xmlns:B="SchemaB.com"
xmlns:C="SchemaC.com"
xmlns:D="SchemaD.com">
</xs:schema> Note that all of the xs:imports below this point would
not be required if WSDL 2.0 followed the XML Schema supported import model
<xs:schema
targetNamespace="SchemaB.com"
xmlns:B="SchemaB.com">
</xs:schema>
<xs:schema
targetNamespace="SchemaB.com"
xmlns:B="SchemaB.com">
</xs:schema>
<xs:schema
targetNamespace="SchemaB.com"
xmlns:B="SchemaB.com">
</xs:schema>
</types>
more WSDL stuff here....
</wsdl>
========================================
WSDL 2.0... as I was hoping it might work ;-)
In this case the hierarchy is represented within my schemas by schema
xs:imports, and resolved by the WSDL processor/schema validator
<wsdl>
<definitions/>
<types>
<xs:schema
targetNamespace="SchemaA.com"
xmlns:A="SchemaA.com"
xmlns:B="SchemaB.com"
xmlns:C="SchemaC.com"
xmlns:D="SchemaD.com">
</xs:schema> Note that all of the xs:imports below this point are not
required within the WSDL 2.0 <types/> They are resolved just like XML
Schemas does now via the validator (and with a WSDL processor)
</types>
more WSDL stuff here....
</wsdl>
J. Bean
P.O. Box 30171
Phoenix, AZ 85046-0171
RDBMS@aol.comXML-Guy@hotmail.com
----- Original Message -----
From: Arthur Ryman
To: RDBMS
Cc: Booth, David (HP Software - Boston)
Sent: Wednesday, July 13, 2005 8:21 AM
Subject: Re: Question re: WSDL 2.0 and (schema) xs:import
James,
If you write an XSD that references another XSD namespace then you MUST
<xs:import> that namespace.
If you write a WSDL that references an XSD namespace then you MUST
<xs:import> that namespace.
Why do you say that WSDL is behaving differently than XSD? Please given me
a concrete example. Thx.
Arthur Ryman,
Rational Desktop Tools Development
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
intranet: http://labweb.torolab.ibm.com/DRY6/
"RDBMS" <RDBMS@aol.com>
07/13/2005 09:34 AM
Please respond to
"RDBMS"
To
Arthur Ryman/Toronto/IBM@IBMCA
cc
"Booth, David \(HP Software - Boston\)" <dbooth@hp.com>
Subject
Re: Question re: WSDL 2.0 and (schema) xs:import
Hello Again,
That is exactly my concern.
If I have a well defined XML Schema hierarchy that functions quite well
and is used by my apps, in order to incorporate it within a WSDL, I have
to manually decompose the hierarchy, navigate the various import syntax
within each schema and sub-schema, and then repeat/redeclare them
(duplication) within the WSDL <types/>.
This reverts back to my original question and concern. Schema does not
function in this manner (you do not declare all the various lower level
imports in the highest level schema), and is the entire point of import
(schema assembly). Also with the current WSDL 2.0 approach, it adds quite
a lot of redundant work.
Is there some rationale why this already implemented schema functionality
has been eliminated with WSDL 2.0 ? Is there some way that I can petition
or request that it be included since it is already existing functionality
of XML Schemas and presents in my opinion a deviation in support for that
W3C Recommendation ?
Thank you for you patience in this matter. It is quite important to many
potential users of WSDL.
J. Bean
P.O. Box 30171
Phoenix, AZ 85046-0171
RDBMS@aol.comXML-Guy@hotmail.com
----- Original Message -----
From: Arthur Ryman
To: RDBMS
Cc: Booth, David (HP Software - Boston)
Sent: Wednesday, July 13, 2005 6:20 AM
Subject: Re: Question re: WSDL 2.0 and (schema) xs:import
James,
That statement is true. The WSDL needs to add an <xs:import> to refer to
any namespaces that the schema imports. Perhaps the following would be
clearer:
"Specifically, namespaces that the schema imports via xs:import cannot be
referenced by the WSDL document unless the WSDL document explicitly
imports them via an xs:import."
xs:import does not import components, it declares that the WSDL document
references schema components from a given namespace.
Arthur Ryman,
Rational Desktop Tools Development
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
intranet: http://labweb.torolab.ibm.com/DRY6/
"RDBMS" <RDBMS@aol.com>
07/13/2005 07:50 AM
Please respond to
"RDBMS"
To
Arthur Ryman/Toronto/IBM@IBMCA
cc
"Booth, David \(HP Software - Boston\)" <dbooth@hp.com>
Subject
Re: Question re: WSDL 2.0 and (schema) xs:import
Thank you !
That is how XML Schema works and what I was hoping would be resolved with
WSDL 2.0. However, it is not what I read in the WSDL 2.0 Draft.
Here is a quote from the WSDL 2.0 draft:
"Specifically, components that the schema imports via xs:import are NOT
available to WSDL."
Thank you !
J. Bean
P.O. Box 30171
Phoenix, AZ 85046-0171
RDBMS@aol.comXML-Guy@hotmail.com
----- Original Message -----
From: Arthur Ryman
To: RDBMS
Cc: Booth, David (HP Software - Boston)
Sent: Tuesday, July 12, 2005 8:31 PM
Subject: Re: Question re: WSDL 2.0 and (schema) xs:import
James,
You only need to explicity import a namespace if you reference it. You do
not need to import namespaces that are referenced by namespaces you
import.
Arthur Ryman,
Rational Desktop Tools Development
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
intranet: http://labweb.torolab.ibm.com/DRY6/
"RDBMS" <RDBMS@aol.com>
07/12/2005 08:57 AM
Please respond to
"RDBMS"
To
Arthur Ryman/Toronto/IBM@IBMCA
cc
"Booth, David \(HP Software - Boston\)" <dbooth@hp.com>
Subject
Re: Question re: WSDL 2.0 and (schema) xs:import
Hi Arthur,
Thank you for your response.
I agree with most of your perspective re: namespaces, but I do not agree
with the notion that this is precisely how schemas work and more
specifically the xs:import declaration and nested schema import references
that cascade through a schema hierarchy.
In particular, the difference is that with XML Schema, I can cascade a
hierarchy of xs:import references, yet do not explicitly need to expose
those import declarations at the highest level of my schema.
The imports of each lower level schema is declared within each of the
schemas where those references are made.
As described by your note and by the WSDL draft, it appears this is no
longer true. We would have to decompose our schema hierarchies and then
individually declare each of the imports as individual "top-level"
xs:imports within the WSDL <types/> section.
In the case of schema, this is not true. I can use only the highest level
parent schema in my application and my validating parser will identify,
acquire and assemble the nested imports from the xs;import declarations
located at any/all points within the hierarchy. I do not explicitly have
to declare xs:import at the top-most schema for all of my sub-schemas that
might be 5 or 6 levels deep and branched out in my hierarchy of schemas.
If I have a somewhat complex set of schema import relationships, having to
navigate and decompose each of those xs:imports so that I can then declare
them individually in my WSDL is both a significant duplication of work and
defeats the purpose of schema reuse.
The way schema works is that unless I am making an explicit QName
reference I only need to know my topmost schema. Lower level import
declarations are unknown to me, yet I achieve reuse because they are
patterned, design and engineered in.
Schema A imports B and C
Schema B imports D and E
Schema D imports F and G
and so on....
With XML Schema, I only need to declare the highest level xs:imports in my
parent Schema A. The others are inherited and unknown to me. They exist
as designed and engineered and I do not need to repeat those xs:import
declarations.
In the case of WSDL 2.0, I would need to manually navigate the syntax of
each imported schema of a schema hierarchy, and then redeclare all of
those imports at a single level within the <types/>, even though they
might have been imported, nested and branched out at varying levels within
the original schema hierarchy.
with XML Schema, the nested and lower level imports allow that my schema
from the top-level is logically one giant schema. with WSDL 2.0, it
appears that this is not longer true and I would need to decompose and
redeclare each of the imports from each and any level (even though I
already have those imports declared within my schema hierarchy).
If I followed the XML Schema model, I would only need to xs:import the
highest level schema and let the WSDL parser navigate any nested imports
as does XML Schema validating parsers.
Hopefully this makes some sense.
Thank you !
J. Bean
P.O. Box 30171
Phoenix, AZ 85046-0171
RDBMS@aol.comXML-Guy@hotmail.com
----- Original Message -----
From: Arthur Ryman
To: RDBMS
Cc: Booth, David (HP Software - Boston) ; www-ws-desc@w3.org ;
www-ws-desc-request@w3.org
Sent: Monday, July 11, 2005 8:41 PM
Subject: Re: Question re: WSDL 2.o and (schema) xs:import
James,
We aren't changing the behavior of xs:import. If a WSDL document refers to
an XSD namespace then it MUST declare that namespace by an explicit
<xs:import>, For example, suppose we have 3 documents, A.wsdl, B.xsd, and
C.xsd, and suppose their target namespaces are A, B, and C. Suppose
further that B.xsd imports C, and that A.wsdl refers to types from both B
and C. Then A.wsdl MUST import both B and C. Even though B.wsd imports C,
A.wsdl must still explicitly import C. This is what we mean by <xs:import>
not being transitive. That's precisely how it works in XSD too.
Arthur Ryman,
Rational Desktop Tools Development
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
intranet: http://labweb.torolab.ibm.com/DRY6/
"RDBMS" <RDBMS@aol.com>
Sent by: www-ws-desc-request@w3.org
07/11/2005 07:40 PM
Please respond to
"RDBMS"
To
"Booth, David \(HP Software - Boston\)" <dbooth@hp.com>
cc
<www-ws-desc@w3.org>, Arthur Ryman/Toronto/IBM@IBMCA
Subject
Re: Question re: WSDL 2.o and (schema) xs:import
Thank you for your response re: WSDL 2.0 and xs:import.
Actually, what I had read and interpreted from the WSDL 2.0 draft is that
cascading schema imports (xs:import) are not supported.
Perhaps a misinterpretation on my part of the "transitive" editor comment
in the draft, but as I read the detail, it appeared that a schema
referenced by xs:import within the WSDL <types/> section that also then
imports another schema directly from within the first schema - but
directly from within the schema, not another WSDL xs:import declaration
(and so on) would not be supported by WSDL 2.0.
This capability (schema xs:import to schema, xs:import to schema,
xs:import to schema etc.) is supported by XML Schemas. I can create a
schema that imports another schema (or several schemas) of a different
namespace, and that schema can then import yet another schema (or several
schemas) of yet another namespace, and so on.
This scenario is quite common in my experience and allows for broad scale
reuse of modular and standard sub-schemas (e.g. representing data
standards, enterprise data structures, common type libraries, etc.).
My question/concern was that as I read the WSDL 2.0 draft with the comment
re: schema import not being transitive, this common and critical
capability of XML schemas (import to import to import and so on) would not
be allowed or supported when the primary/parent schema (the one doing all
the subordinate imports) is imported within the WSDL <types/> section.
Hopefully this makes some sense ;-)
Any information, clarification, or confirmation is much appreciated !
Thank you !
J. Bean
P.O. Box 30171
Phoenix, AZ 85046-0171
RDBMS@aol.comXML-Guy@hotmail.com
----- Original Message -----
From: Booth, David (HP Software - Boston)
To: RDBMS
Cc: www-ws-desc@w3.org ; Arthur Ryman
Sent: Monday, July 11, 2005 4:12 PM
Subject: RE: Question re: WSDL 2.o and (schema) xs:import
James,
Perhaps you were thinking of wsdl:include or xs:include?
-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com]
Sent: Monday, July 11, 2005 5:20 PM
To: RDBMS
Cc: Booth, David (HP Software - Boston); www-ws-desc@w3.org;
www-ws-desc-request@w3.org
Subject: Re: Question re: WSDL 2.o and (schema) xs:import
James,
We don't want to change the behavior of <xs:import>. It is not transitive
in XSD. You need to explicitly import a namespace in any XSD that refers
to it.
Arthur Ryman,
Rational Desktop Tools Development
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
intranet: http://labweb.torolab.ibm.com/DRY6/
"RDBMS" <RDBMS@aol.com>
Sent by: www-ws-desc-request@w3.org
06/28/2005 08:32 PM
To
<www-ws-desc@w3.org>
cc
<dbooth@hp.com>
Subject
Question re: WSDL 2.o and (schema) xs:import
I've been doing some research on the draft of WSDL 2.0 and found the WSDL
2.0 editorial note re: "xs:import not being transitive".
I am somewhat concerned as xs:import (both cascading through and across
multiple target namespaces) is both a valuable and critical capability of
XML Schema.
The ability to import a cascading chain of namespace qualified resources
from multiple schemas (and multiple targetNamespaces) is core to reuse of
modular schema artifacts.
I am not sure why this capability would be eliminated from WSDL ?
I've not found further annotation as to discussion or possible resolution
of the question and was hoping that you might provide additional insight
or perspective, or possibly help to influence the WSDL 2.0 to consider how
important this capability is.
Thank you !
James Bean
RDBMS@aol.com