RE: NameValue and NameValueList data types

 Jorgen,
 I think you're overly pessimistic in what the world can do and
what it wants. On the latter, I doubt you'd want my weather
report service to be interoperable with your purchase order
service. So if we imagine a client designer, she knows what the
service expects and provides. Even if an array of structs (the
map as represented by Apache) is mapped into an array of structs
in the client's implementation, the client application can still
work with it.
 On the former - many implementations have agreed to use the
Apache way for maps, including Systinet WASP. I think this is
exactly the "third-party-spec extensibility" which SOAP envisions
and calls for.
 In your turning my assertion around, you were completely
correct. The WG currently seems to tend to accept removing sparse
and partially transmitted arrays from the Encoding, see [1] for
a proposal in that direction.
 Of the three possible homes for the definition for complex
structures (XMLP is now SOAP), to me it seems that XML Schema is
the most appropriate place, namely XML Schema Type Library which
is currently being worked on.
 Actually, had the XMLP WG started from scratch and had XML
Schema been in Recommendation at the time, I doubt XMLP would
even have any kind of Data Model and Encoding. Ultimately, this
is out-of-scope for an XML communication protocol. Imagine the
HTTP RFC defining HTML. 8-)
 Microsoft and other implementors have shown considerable
commitment for interoperability efforts. Even if Microsoft
refuses to embrace the Apache serialization of maps and comes
with their own, what stops the Apache folks and others from
implementing that one instead?
 I don't think the world will go back into "walled camps" in
which it was some ten years ago, it's too small for that now.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0248.html


On Thu, 20 Dec 2001, Jorgen Thelin wrote:

 >
 > 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
 >

Received on Thursday, 20 December 2001 11:24:49 UTC