RE: Importing schemata into WSDL

Jacek:

Response inline.

Don

-----Original Message-----
From: Jacek Kopecky [mailto:jacek@systinet.com]
Sent: Thursday, October 17, 2002 11:19 AM
To: Don Mullen
Cc: 'Sanjiva Weerawarana'; WS Description WG
Subject: RE: Importing schemata into WSDL

Don,

I disagree with points 1 and 3 from my experience of having implemented
(or cooperated on) a set of WSDL tools.

Don> The problem is not WSDL tools, that obviously would be aware of
whatever is standard for WSDL, it is compatibility with non-WSDL tools that
matters for issue #1.

Don> I would be interested in hearing how you solve issue #3.  Is your
solution interoperable?  It seems to me the potential for having two type
definitions that claim to be the same type, a truly complete tool would need
to verify that the types are the same.  If  you don't do that, you are
simply ignoring the problem, which, in my  mind, leaves this objection on
the table.

4 should not be a problem because published schemas should seldom or
never change; also many WSDL use unique namespaces so schema management
is mostly a schema replacement anyway. 8-)

Don> A good self-fulfilling prophecy here.  Since it is difficult to share
these schemas, they are not shared outside of WSDL.  Since they are not
shared outside of WSDL, we don't need to share them.  Hmmm.  We've been
actively developing a schema / xml management tool for the last few years.
Schemas/WSDLs do change during the development cycle -- sometimes by
multiple people across multiple organizations.

6: well we want to say something about message parts. I think you have
nothing against importing external schemata, so really the analogy to
XSLT doesn't work because it isn't used in WSDL at all at the moment. So
I feel point 6 is pretty much void.

Don> Your argument misses the analogy.  For comparison, XSLT 2.0 is adding
validation, but they aren't talking about including schemas "inline" in
XSLT.  Of course we need to use schema to define types, but we don't
necessary have to include them inline.

I agree completely with point 7. 8-)

Don> Great -- we're making progress! ;-)

XML syntax, especially namespaces, was explicitly designed for easy
vocabulary combinations, and this is directly against your point 8.

Don> Just because it is possible, doesn't mean it is a good idea.  Auto
manufacturers could sell cars that come pre-bundled with four spare tires,
but that is not really useful, as you (almost always) only need one spare
tire.  Interoperability and backward compatibility is key -- embedded
schemas don't work well with non-WSDL tools.

To conclude, I disagree with most of your points and I prefer we keep
the ability to embed schemata (because in some applications it really
simplifies distribution or processing) together with the ability to
refer to external schema documents.

Don> You seem to have argued against most points by indicating that they
aren't valid issues.  I would argue that WSDL is currently not being used to
its fullest potential -- having been thus far basically restricted to fairly
simply request/response / SOAP over HTTP.  Expanding its use into the
enterprise-wide pub/sub space raises many schema and wsdl management issues
that some people may not have encountered. 

Don> It seems unlikely that I am going to win this argument (especially
since I've heard no one in the group support this view!).  I would like to
see some text in the spec, however, that indicates that although embedded
schemas are supported in WSDL, best practice dictates that schemas be
imported.

On Thu, 2002-10-17 at 16:50, Don Mullen wrote:
> 
> Sanjiva:
> 
> Some reasons not to include embedded schemas within WSDL files:
> 
> 1) Schema inclusion makes life difficult for tool builders.  Although the
> difficulties can be overcome, it is sometimes difficult to get
interoperable
> results with tools that don't get this right.
> 
> 2) No identifiable location... some XML validators will be hard pressed to
> make use of the embedded schemas without having a physical location URI.
> XML instance documents cannot reference embedded schemas via
schemaLocation.
> This could be dealt with using some sort of "inside of" or fragment URI
> convention, but again there isn't a clear interoperable way to do this.  
> 
> 3) Embedding a shared (or 3rd party) schema into several WSDLs, just for
the
> simplicity aspect, can trip up systems that expect only one schema per
> namespace... now you have to pick one, or compare them, or something.
> 
> 4) Schema management across the organiziation becomes more difficult when
> you have schemas both in stand-alone documents and embedded within WSDLs.
> The embedded schemas would rarely be reused.
> 
> 5) In some sense (perhaps niave), it creates an expectation that WSDL
> defines types (is a schema language).
> 
> 6) If we are going to include schemas, why don't we also include XSLT
> operations, since it might be desirable to describe a transformation of
the
> service request or result.  That is more obviously a silly idea.
> 
> 8) The only reason that these two were combined to begin with stems from
> both WSDL and XML Schema both being in XML syntax, and is convenient in
> simple stand-alone cases.  If, instead a non-XML metadata file was
> referenced, everyone would know from the get-go that the two needed to be
in
> separate files.
> 
> Don

Received on Thursday, 17 October 2002 18:27:33 UTC