- From: Rich Salz <rsalz@zolera.com>
- Date: Tue, 20 Nov 2001 09:36:19 -0500
- To: Alan Kent <ajk@mds.rmit.edu.au>
- CC: xml-dist-app@w3.org
> I probably sound like a broken record, but I personally feel its bad > for interoperability for a spec to define a concept and then say > 'but its application specific.' The spec should completely > define what is within the scope of the spec and not specify > anything that is not within scope of the spec. No, it's a good thing. It gives application builders a handle on how to do something they might need to do. It can be confusing that three common cases are boiled down into one wire-level construct, but since those cases are non-overlapping, it actually *simplifies* the work of the SOAP implementor. > The reality is SOAP toolkits are built to handle the SOAP spec. > If the toolkit implements the semantics, then the application > does not get a choice. If the application wants implements the > semantics, then the toolkit must support 3 states for each slot > in all arrays: null, omitted, or a real value. The SOAP toolkit cannot completely implement the semantics, and it never could -- too much meta-data (datatype) information was *always* required for the "just-SOAP" library to be able to properly implement everything. It could make its own decisions, or it could require type information (XSD or what have you) to help decide, or it could require the application to completely specify things. SOAP encoding is not TCP, it is data serialization, and there are times when serious application-provided information is needed. There's just no way around it. > the spec says a protocol implementation > is allowed to translate an omitted value into null Actually, it seems to me that the spec is very careful to talk about application semantics, and not protocol implementations per se. /r$ -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com
Received on Tuesday, 20 November 2001 09:36:48 UTC