W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2002

Re: Proposal for dealing with root, top-level multi-refs and encodingStyle

From: Martin Gudgin <martin.gudgin@btconnect.com>
Date: Tue, 7 May 2002 09:37:55 +0100
Cc: xml-dist-app@w3.org
To: noah_mendelsohn@us.ibm.com
Message-Id: <BA1D4A46-6195-11D6-866E-00039384A3E4@btconnect.com>
I'm not entirely convinced that we need the notion of root either, but 
the editors have an outstanding TODO ; 'Add the notion of root to the 
data model'

I agree that your example below is good RPC even though the EII 
representing the RPC call is not the root of the graph.

Gudge

On Monday, May 6, 2002, at 08:53  pm, noah_mendelsohn@us.ibm.com wrote:

> Overall, I like this, but I have one question:
>
>>> 1. State that the notion of root in the data
>>> model is as follows: "A graph node is said
>>> to be a root of the graph if it has no inbound
>>> edges".
>
> Is this concept used in your formulation? For example, if I had the
> following:
>
> <s:header>
>         <x:e ref="a" s:encodingStyle="..soap encoding..."/>
> </s:header>
> <s:body>
>         <y:getStockPrice id="a" s:encodingStyle="..soap encoding...">
>                 <y:company>GizmoWare</y:company>
>         </y:getStockPrice>
>
> </s:header>
>
> getStockPrice is a struct with an inbound edge, hence not a root.  Yet,
> it's still a good RPC, right?
>
> Bottom line:  if we need and use a notion or root, then I agree it 
> belongs
> in the data model, and I think you have the details right.  I'm not 100%
> convinced we need it.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
>
> Martin Gudgin <martin.gudgin@btconnect.com>
> Sent by: xml-dist-app-request@w3.org
> 05/06/2002 03:04 PM
>
>
>         To:     xml-dist-app@w3.org
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Proposal for dealing with root, top-level 
> multi-refs and encodingStyle
>
>
> In the past we have tried to talk about the notion of root, top-level
> multi-refs and encodingStyle seperately.
> Here is a proposal that looks at all of them at the same time in order
> to produce a coherent solution.
>
> In the current description of the SOAP Encoding, outbound
> edges of a graph node are encoded as child EIIs which means that a given
> serialization will always have a single top-level serialization
> root. Multiple top-level serialization roots can only be
> achieved by cross referencing between serialization trees.
>  From the SOAP Encoding perspective, such practice will still
> result in but a single graph upon deserialization.
>
> So, we have a very clear mechanism for establishing
> multiple roots by cross referencing between serialization
> trees when this is desired. We avoid having non-roots
> being mistaken for roots by inline serialization within a
> single serialization tree when this is desired.
>
> Given this, the notion of root at the serialization level
> seems unnecessary and the
> notion of root in the data model seems trivial to state.
>
> In the special case of the RPC convention, we clearly state
> that a call and a response is modeled as a single struct
> which prohibits a Body EII from containing multiple roots.
> One could of course imagine cross referencing to a header
> block but that would still explicitly mark the single struct
> in the Body as the "call" or "response". Hence, in this case,
> the "root" AII is not needed either.
>
> Which brings us to encodingStyle AII. Currently the
> encodingStyle AII applies to the EII it appears on and
> that EII's descendants. In the RPC case this means the
> child of the Body EII and *not* the Body EII itself. The
> reason is that the call and response is identified as a
> single struct, and that struct is *not* the Body EII but a child EII of
> the Body EII.
>
> The encodingStyle AII does not make sense on soap:Envelope,
> soap:Header as those elements are defined in our spec and do
> not have an encoding style. In fact, the schema description
> of Envelope and Header already disallow attributes from the
> http://www.w3.org/2001/12/soap-envelope > namespace.
>
> While potentially possible to use the encodingStyle AII in non-RPC
> convention cases and have the Body EII be modeled as a
> struct, this doesn't seem to be an interesting edge case to
> support. In the interests of consistency I would therefore argue that we
> disallow the encodingStyle AII on Body too.
>
> So, in terms of concrete changes to our spec;
>
> 1. State that the notion of root in the data model is as
> follows: "A graph node is said to be a root of the graph if
> it has no inbound edges".
>
> 2. In Part 1 Section 5.1.1 state that encodingStyle AII is
> only legal on descendants of soap:Header and soap:Body ( and
> probably soap:Detail ) by stating:
>
> "The encodingStyle attribute MAY appear on any element
> information item in a SOAP message except those whose
> [namespace name] property has the value
> "http://www.w3.org/2001/12/soap-envelope""
>
> 3. Amend the envelope schema as follows: Change the value of
>
>  /xs:schema/xs:complexType[@name='Body']/xs:anyAttribute/@target
>                  Namespace to ##other ( from ##any ).
>
> Regards
>
> Gudge
>
>
>
Received on Tuesday, 7 May 2002 04:39:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT