Summary: AD Feature Related Issues

The following AD feature related issues surfaced while discussing header
proposals.


(a) From Prasad Yendluri [1], relates to ad:mustUnderstand [2], " This
indicates at the abstract level that the particular element thus decorated
is mandatory, and implementations of this feature which support expression
of mandatory data (i.e. the Application Data SOAP Module, see 3.2
Application Data Module) should mark them as mandatory in an appropriate
way."

If the property is true, then the bindings that support expression of
mandatory data should mark 
them as mandatory in an appropriate way.

Why is it a "should mark them as mandatory" and not a "must"? With this it
seems a specific SOAP binding can choose not to mark the headers with
"mustUnderstand=true" even when at the interface/operation 
level {header} components sets this attribute to true.


(b) From Prasad Yendluri [1], relates to Application data serialization as
HTTP headers [3], " then each of the top-level child element information
items indicates an element information item that MUST be turned into an HTTP
header if possible."

Eliminate use of MUST and "if possible" in the same sentence above.


(c) From Roberto Chinnici [4], relates to Application Data Property [5], I
don't fully understand this issue. Listing it anyway.

Certainly those are all issues, but the core of my concern is that, just
because XML Schema doesn't offer good support for versioning, we shouldn't
devise our own abstract formalization of the multi-block SOAP envelope. I
don't see any intrinsic reason why a schema language shouldn't be able to
support versioning out of the box in a humanly comprehensible form, without
any need for SOAPisms. Such a discussion is best left to working groups
dealing with those languages, rather than ours.


(d) From Amy Lewis [6], relates to Application Data Property [7]

> Information about binding requirements are buried in the type
> system, requiring an author to find the required use (in the
> example) of

it can't be validated using existing XML Schema tools; it's effectively a
different schema language with a passing resemblance to XML Schema

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. 


[1] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0054.html
[2] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-mu-att
[3] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-http-op
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0082.html
[5] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#app-data
[6] http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0003.html
[7] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#adf-dp-desc

Regards,
Asir S Vedamuthu
asirv at webmethods dot com
http://www.webmethods.com/

Received on Thursday, 3 February 2005 15:08:09 UTC