W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

Re: NameValue and NameValueList data types

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>
Message-ID: <Pine.LNX.4.33.0112211149400.10459-100000@mail.idoox.com>
 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)
Received on Friday, 21 December 2001 07:56:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC