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.


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 UTC

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