RE: SOAP Header Blocks in WSDL (was RE: First Class Headers - Pr oposed Resolution for LC76d

> Hmmm.  And that feature is also guilty of failure to 
> validate, for that matter, creating the same sort of 
> bogus complex type definition

That is an AD feature issue. I inherited via re-use. In this discussion,
thus far I have collected 5 issues on status quo. I'll summarize them.

> ADF also provides an HTTP serialization, and restricts 
> the content of headers intended for serialization in 
> HTTP to string or anyURI (but not QName, interesting)

If this is the chosen approach, nothing should stop us from extending it to
HTTP binding. 

> Ah?  Add additional features/properties that contain new 
> requirements to the binding. 

There is a reason why I asked. If there are additional properties, .. Given
that, "If a given property is asserted at multiple locations, then the value
of that property at a particular component is that given by the nearest
assertion in lexical scoping order" [1]. My understanding is that you are
re-writing not extending. That is, you are starting from scratch, just like
the way you mentioned [2].

[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Property_composition_model
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0097.html

Regards,

Asir

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Amelia A Lewis
Sent: Wednesday, February 02, 2005 3:46 PM
To: Asir Vedamuthu
Cc: www-ws-desc@w3.org
Subject: Re: SOAP Header Blocks in WSDL (was RE: First Class Headers - Pr
oposed Resolution for LC76d



Dear Asir,

On Wed, 2 Feb 2005 14:05:57 -0500 
Asir Vedamuthu <asirv@webmethods.com> wrote:
> > 1) it can't be validated
> 
> I didn't say that. It can be validated. But, the order is
> insignificant.

Nope.  I did.  It doesn't contain a splat to permit other headers, it
enforces order.

So I'll correct my statement: it can't be validated using existing XML
Schema tools; it's effectively a different schema language with a
passing resemblance to XML Schema.

> Similar (not the same) to http://www.w3.org/XML/Group/2000/11/lc200
> (member only).

Member-only note last modified in 2000?

> > 3) it's brittle
> > A deployed service cannot reasonably and easily extend the types
> > defined for headers in a way that describes new requirements,
> 
> I like to know how status quo supports this.

Ah?  Add additional features/properties that contain new requirements to
the binding.  Using WS-Policy, do this in an external document that
points into the WSDL.

> > 4) it's obscure
> > Information about binding requirements are buried in the type
> > system, requiring an author to find the required use (in the
> > example) of
> 
> I like to know how status quo supports this. BTW, in Part 2, section
> 3.1.4,
> http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-dp-desc,
> required, optional, choice, maxOccurs, etc. are buried in the type
> system.

Hmmm.  And that feature is also guilty of failure to validate, for that
matter, creating the same sort of bogus complex type definition as this
proposal.  How annoying.  The AD feature does have the grace of putting
a generic marker into the binding and, for that matter, can be
serialized into HTTP headers as well as SOAP headers.

So ... hmm.  ADF also provides an HTTP serialization, and restricts the
content of headers intended for serialization in HTTP to string or
anyURI (but not QName, interesting).  SOAP header blocks is then a
SOAP-specific proposal?  If so, why prefer it over something that can
(and is shown to) be bound to other situations in which, as David
Orchard has noted, there is a division between "message headers"
(metadata) and "message body" (content)?

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 3 February 2005 13:49:14 UTC