- From: Jacek Kopecky <jacek@systinet.com>
- Date: Fri, 21 Dec 2001 13:56:42 +0100 (CET)
- To: Pete Hendry <peter.hendry@capeclear.com>
- cc: <xml-dist-app@w3.org>
Pete, first, SOAP Encoding and XML Schema have very different goals. XML Schema is meant as a language for validation of documents, therefore it for example contains the facets that allow to restrict integers to positive integers. I think that positive integers need not be in the core XML Schema - Datatypes spec, but then everybody using them would just use the integer with the same facets and this is an optimization. There would be no interop issues with differet representations of positive integers because the definitions would validate the same XML documents with the same results. On the other hand, SOAP Encoding means to be a set of rules for representing data structures in XML. It indeed needs to say how to represent every possible data structure, but it can accomplish the task in a very simple way like this: "every possible data structure is a graph of structs and arrays and primitive types" and leave the mapping on the application. SOAP Encoding is not meant to be used for validation therefore it needs not be able to say that a given array of structs is a map or it is Properties or it is an NVL or whatever. It's the application that gives the meaning to the array of structs. Yes we could specify the common representations of the common higher-level structures, but this would be built on top of SOAP Encoding and would not (could not possibly) be mandatory, therefore it would be another document (chapther, whatever). The layering is important, an implementation can support the core SOAP (communication protocol), it can support SOAP Encoding natively, it can also support SOAP Encoding Higher Level Data Structures natively, but we don't want every implementation to implement KeyValueLists, ArraySegments, SparseArrays, BinaryTrees, OtherTrees, LinkedLists, DoublyLinkedLists, DiscriminatedUnions etc. They all can be implemented as add-ons. And I don't see your KeyValue structure as more important than, for example, a Triple. KeyValues are used more often, but the structures are on the very same level of abstraction. Do you propose we add Triples, too? Back to standards: JAX interfaces usually focus on the Java side and let the implementation do its stuff on the lower levels, so I think it would be an implementation's responsibility to specify how it represents Maps, Sets, Lists etc. if the JAX interface required that. I may be mistaken in how it works in the JAX world, though. Jacek Kopecky Senior Architect, Systinet (formerly Idoox) http://www.systinet.com/
Received on Friday, 21 December 2001 07:56:44 UTC