- From: Amelia A Lewis <alewis@tibco.com>
- Date: Wed, 2 Feb 2005 15:45:09 -0500
- To: Asir Vedamuthu <asirv@webmethods.com>
- Cc: www-ws-desc@w3.org
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 Wednesday, 2 February 2005 20:45:34 UTC