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

Re: Modeling RPC with UnitData

From: <Noah_Mendelsohn@lotus.com>
Date: Fri, 20 Apr 2001 11:05:19 -0400
To: rden@loc.gov
Cc: xml-dist-app@w3.org
Message-ID: <OF4C660F42.5FB8B68B-ON85256A34.00531E21@lotus.com>
One thing that comes up as a result of recent discussion on soapbuilders 
is the question of references to encoded data that spans headers.  In SOAP 
terms, I can have multiref objects on one header, and reference from 
another.  That doesn't specifically say unitdata isn't enough, but it 
suggests a lack of modularity in the headers that might need to be 
reflected at a core layer.  Not sure, but I think we should leave 
ourselves room to discuss this at the right time.  Thanks.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Ray Denenberg <rden@loc.gov>
Sent by: xml-dist-app-request@w3.org
04/11/01 06:24 PM
Please respond to rden

        To:     XML Distributed Applications List <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        Modeling RPC with UnitData

I was asked by the WG to draft a resolution to the question of abstract 
of RPC; namely, is the UnitData primitive sufficient at the XMLP layer to 
RPC?   (The actual question was whether the UnitData primitive needed a
response-required parameter.)

One theory is this: It has now been agreed that RPC will be represented by 
module,  modeled on top of the XMLP layer, and it therefore does not need 
to be
represented by a state machine within the XMLP layer itself (thus the RPC 
of a transaction is not visible to XMLP).

To bring this issue to resolution, I would like to ask if there is anyone 
comfortable with this approach. I am tasked with proposing a solution by 
Monday; if there is no response to this, that is what I will propose.


Ray Denenberg
Library of Congress
Received on Friday, 20 April 2001 11:08:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC