- From: Marc Hadley <marc.hadley@sun.com>
- Date: Tue, 10 Sep 2002 15:53:48 -0400
- To: noah_mendelsohn@us.ibm.com
- Cc: Jacek Kopecky <jacek@systinet.com>, Martin Gudgin <mgudgin@microsoft.com>, XMLP Dist App <xml-dist-app@w3.org>
On Tuesday, Sep 10, 2002, at 15:31 US/Eastern, noah_mendelsohn@us.ibm.com wrote: > You point out that RPC rules out more than a single child header. Not header, a single child of the Body EII. That child being the serialized invocation or response struct (or array). > Where > do we stand on encodings that span from body to header? I don't think we say anything about that. We certainly don't prohibit it (AFAIK). > Though I > certainly not encourage it me either... > , that would allow in principle for one root to > be in a header (my X element) and another in the Body, even for RPC. True, good point. > So, > I think it's important for interop that we be clear on what is and is > not > allowed, and what the interpretation of each legal form is in terms of > graphs. I'm still a bit vague on what the status quo is saying. > Thanks. > For RPC, the key thing is knowing where to start and I think that is clear in the current spec. The question of whether the resulting struct or array can have parts in the header I don't think we have answered. Prohibiting this could prove quite onerous on implementations which would then have to check that referenced elements are descendents of the same header block or body as the referent. For encoding in general I don't think we really need to say much more than we do already. Other applications of encoding may restrict its instantiation much as we do for use in RPC but that can be left to those applications. Regards, Marc. > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------ > > > > -- Marc Hadley <marc.hadley@sun.com> XML Technology Center, Sun Microsystems.
Received on Tuesday, 10 September 2002 15:53:50 UTC