- From: Pete Hendry <peter.hendry@capeclear.com>
- Date: Fri, 21 Dec 2001 00:42:48 +0000
- To: Jacek Kopecky <jacek@systinet.com>
- CC: xml-dist-app@w3.org
> And about .net, perl, python etc: a map is a list of key-value > pairs. Naturally represented as an array of structs. That's how > Apache does it. How else can .net or python implementation > represent a map _on_the_wire?_ Yeah, they can change the > namespaces or stuff, but the logical structure will be the same. > Therefore it's as well for them to accept what's already out > there. The focus appears to have fallen on Map but that is not why I was proposing KeyValue. This is the problem with the current approach. Apache has defined a way to define Map. As a side effect they have defined 'pair'. However, it is 'pair' that is the basic building block for other types, not Map. Map is one type to build from KeyValue. Others include properties (in java - ok, also a Map but not quite the same), NVLs in Corba, and examples such as representing a list of HTTP headers, as well as similar data types in most (if not all) other languages. As I said before, I think adding KeyValueList is not required as it does not represent a basic building block for other types, but KeyValue does. It's one of those things that if you coded it often enough in your programming language you'd get tired of it and create a library version that you always use. Take for example the JAX interfaces. Are they going to reference Apache schema for some of their types, and then have a schema of their own, for example, for Collection types not defined by Apache? At least collections can be build as an array of Objects and so build on core types. The same is not true for Maps, etc. Pete
Received on Thursday, 20 December 2001 19:44:51 UTC