Re: DR201, DR202 and DR203: Programming Language Bindings

> DR201,202 and 205 all relate to programming language bindings.
> 
> 	DR 201 states "...There will be straightforward mappings of the data
> types used to a wide variety of widely deployed programming languages and
> object systems." 
> 
> I am concerned that we have some sense of canonical representation on the
> wire that has well understood semantics. It's not clear to me that the XP-WG
> will define language bindings for any particular programming languages...
> indeed I would advocated not. However, merely requiring the existence of
> "straightforward mappings" does not necessarily lead to a single mapping for
> a given programming language. I think the important thing is the
> representation and meaning of information on the wire rather than how that
> same information is represented by a particular language binding to a given
> programming language.

I thought that binding to programming languages was the whole point of 
defining yet another way of serializing objects.  Otherwise, we would 
just use XML and schemas, which works just fine "on the wire" as has 
been repeatedly demonstrated by implementers.  It's form on the wire is 
of little importance compared to it's importance in the sender and 
reciever's programming context.  Suggesting that we should model it 
emphasizing it's form on the wire and downplaying it's characteristics 
WRT the sender's and reciever's program objects' context seems to me to 
destroy every argument for it in the first place.  A wire format is not 
an adequate object model, requirement, or motivation for this set of 
requirements.

> 	DR 202 "The XML Protocol will allow applications to include custom
> encodings for data types used for parameters and results in RPC messages.
> Mechanisms for automatically binding data represented in RPC messages to
> native constructs in a programming language will not be precluded."
> 
> This seems to be a statement of two requirements, one in each sentence. The
> first is a requirement to allow custom encodings for parameters and results.
> Given a need to define define meaning from an on the wire point-of-view, I
> am concerned about the interoperability issues that will arise through the
> 'rampant' use of custom encodings - will there be mechanisms that enable the
> initiator of an interaction to determine which (non-default) encoding to use
> in a request message?

Languages may have different common native objects that need to be 
encoded.  This is like objects passed by value in other RPC systems, 
which require local interpretation at each end that is known to the 
language binding.  Every language is likely to become a custom encoding 
anyway onto the wire format, if all the focus is on the wire format.  
There are certainly many equivalent ways to use every wire format I have 
ever seen, unless, as in the case of CORBA or COM, you tie down how the 
wire format is bound to the language.

> I would also be inclined to delete the second sentence of DR 202.
> 
> 	DR203 "The XML Protocol will guarantee that RPC messages that encode
> parameters and results using the default encoding for the base set of data
> types will be valid for any conformant binding of the RPC conventions.
> "Valid" in this context means that the semantics of the call should remain
> identical, irrespective of the programming language or object system used by
> the caller or receiver."
> 
> I share Noah's concern [1] that we define semantics from the point-of-view
> of what is represented on the wire and the need for clarity over the
> difference between 'programming language' bindings and 'transport protocol'
> bindings. On first reading I thought that this requirement was oriented
> around the preservation of programming language invocation semantics (in a
> distributed cross language environment) rather than the programming language
> independent semantics of the request and response XP messages. I think that
> this requirement could be re-worded to reflect a wire oriented view rather
> than a PL oriented view.

And, IMO, make the whole section irrelevant by ignoring what we are 
trying to do with this, which is bind to PLs.  I can come up with lots 
of better alternatives if the object is not to bind to PLs, but it is 
hard, then, to see where the requirements are coming from.

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 14 November 2000 14:26:52 UTC