RE: NameValue and NameValueList data types

The problem we (as an industry) have is that until we standardize the
representation of a name-value list, we will never achieve any true
interoperability of such a fundamental programming language construct as
name-value pairs.  An "Apache standard" for this type representation is not
going to provide this, neither is a Java representation or .Net
representation on their own - best case that gives us one representation for
each programming language, and worst case one for each soap implementation.

I do take your point that we cannot even hope to standardize the
representation of all possible types, and nor would we want to, but surely
we should try to specify all the *base* types to allow all the more complex
and industry / application specific types to be constructed from these.  
My assertion would be that name-value lists are part of this base type
group, not part of the composable group.  
Without this, every language mapping from WSDL has to recognize every other
possible "name-value like" schema type to map it correctly to the
appropriate native language type (java.util.HashMap in Java,
System.Collections.Hashtable in .NET, Hashes in Perl, etc.)

Turning your assertion round, Jacek, if partial and sparse arrays are
included, then IMHO so should name-value lists!  Both items seem to fall
into the "representations that cannot be constructed using schema
definitions in an interoperable fashion" group to me.

The real problem seems to come down to which spec this type of standardized
type encoding should be included in?  SOAP?  WSDL?  XML Schema?  XMLP?
The most natural place would seem to be the SOAP standard, which now falls
under the remit of this working group I believe, and which XMLP will
ultimately replace.  Correct me if I am misunderstanding the scope of this
group.

I think the Apache experience quoted below proves the need for standardizing
this representation, but without a single standard for this then all the
good work achieved so far by SOAP in improving interoperability between
Microsoft and Java/Non-MS systems will be destroyed or severely limited.
The worst possibly thing that could happen to this industry is if we slip
back into the "Walled Camps" view of the world where we have to spend all
out time building bridges!


	Jorgen Thelin
	Chief Architect, CapeConnect
	Cape Clear Software Ltd.
	http://www.capeclear.com


> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com] 
> Sent: 18 December 2001 00:50
> To: Pete Hendry
> Cc: xml-dist-app@w3.org
> Subject: Re: NameValue and NameValueList data types
> 
> 
>  Pete,
>  the WG has decided before that adding types is not the way 
> to go in SOAP Encoding. There's actually an ongoing battle of 
> some to remove some types, namely partial and sparse arrays.  
> As the Web has demonstrated, people can actually talk to each 
> other in a simple and extensible environment for they will 
> build extensions and if important, the de-facto standard will 
> eventually appear. Obviously, XML is the ultimate in this 
> direction.  Now in XMLP WG we're working on a protocol for 
> messaging in XML, and we accepted SOAP as our base that needs 
> some tweaking resulting in the experience we've gained with 
> it, just like some chemistry WG can work on an XML language 
> for chemical documents, based on one or a few existing 
> chemical languages. This is GOOD(tm), but let's not try to do 
> too much. Already some people feel RPC and encoding is too 
> much.  If we simplify the RPC and Encoding and if we make 
> explicit the optionality thereof, it might become clear that 
> we think that the core value of our work is the SOAP 
> messaging, not Encoding nor RPC, though these might (and 
> will, guaranteed) be useful.  Apache soapers have already 
> shown that where maps are needed, they are specified, and 
> others have demonstrated that they can accept the reasonable 
> proposal by Apache. Taking your proposal to the extreme, do 
> you think it would be good if the XMLP WG tried to specify 
> every useful high-level data structure in its Encoding 
> section? And if we say "it can go into a separate section, 
> building on the Encoding", the XMLP WG has a response:  It's 
> out of scope of _XML_Protocol_.  Anyhow, if SOAP specified 
> NameValueLists in a section separate from the Encoding, as I 
> just suggested, IMHO partial and sparse arrays should go 
> there, too. 8-)  Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> 
> 
> 
> On Mon, 17 Dec 2001, Pete Hendry wrote:
> 
>  >
>  > One datatype that soap does not currently have is the 
> concept of a NameValue list (KeyValue list, Map, Hash, etc).  
> > Vendors are defining their own (such as Apache) and hoping 
> that others will use them so that they can interoperate.  > 
> However, since this name/value concept is suported as 
> standard in just about every programming language I think it  
> > should be a candidate for a data type in SOAP.  >  > Apache 
> defines the notion of a Map of Pairs. I would like to use the 
> more general NameValue and NameValueList  > definitions with 
> which a Map can be represented.  >  >
>  >   <complexType name="NameValue">
>  >     <sequence>
>  >       <element name="name" type="xsd:anyType" />
>  >       <element name="value" type"xsd:anyType" nillable="true" />
>  >     </sequence>
>  >   </complexType>
>  >
>  >   <complexType name="NameValueList">
>  >     <complexContent>
>  >       <restriction base="SOAP-ENC:Array">
>  >         <sequence>
>  >           <element name="nv" type="xsd1:NameValue"
>  >                    minOccurs="0" maxOccurs="unbounded"
>  >                    nillable="true" />
>  >         </sequence>
>  >         <attribute ref="SOAP-ENC:arrayType" 
> wsdl:arrayType="xsd1:NameValue[]" />
>  >       </restriction>
>  >     </complexContent>
>  >   </complexType>
>  >
>  > In the Java community this would preempt JSRs such as 
> JAX-RPC creating their own mappings which may not be agreed 
> by the  > non-java community and interop breaks down.  >  > Pete  >
>

Received on Thursday, 20 December 2001 06:03:27 UTC