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

RE: Proposed resolution: issues 78, 16

From: Jacek Kopecky <jacek@idoox.com>
Date: Mon, 6 Aug 2001 23:33:13 +0200 (CEST)
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
cc: <Noah_Mendelsohn@lotus.com>, <mlong@phalanxsys.com>, <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0108062316590.20368-100000@mail.idoox.com>
 Henrik,
 I also like the separation of data model and the actual
encoding, but here I must say that I don't think defining an
abstract data model is needed. Let me elaborate.
 If we define an abstract data model, we can either mandate it
for every encoding ever used with SOAP; or we can make this data
model optional. I don't think that we can successfully mandate a
programming data model (such as implied by section 5) for an XML
protocol. So it would be optional.
 So we would define a data model and one of its possible XML
renditions - the current section 5 encoding.
 Here I have a question - why would we want to allow other
serializations of the abstract data model?
 But let's suppose we have an abstract data model and one
concrete encoding of it. Now we again have some options, three
this time:
 1) We can build RPC upon the abstract data model. See [1] for my
reason why not to do so.
 2) We can build RPC upon the concrete encoding of the abstract
data model, so we would say: "RPC is modeled as a struct in
section 5 encoding, this struct is the only serialization root in
the Body." This way we would not allow the "different encoding -
different RPC struct representation" problem show in [1].
 3) We can build RPC of elements and only reference serialization
where it's needed. See my (j) wording in [1] again. This way we
don't mandate any encoding nor do we mandate any data model and
we still have unambiguous rules on how the RPC call would be
serialized. This is my favorite.

 I think one abstract data model will never satisfy everybody,
and even if a simple data model and encoding is ok in 80 per cent
cases, why should we tie RPC to it if we don't have to? This is a
real question, not a rhetorical one. 8-)
 Best regards,

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0063.html




On Mon, 6 Aug 2001, Henrik Frystyk Nielsen wrote:

 >
 > >As
 > >I have said before, it might be nice to do a simple job of naming data
 > >models.  Then we can say:  "The default data model for SOAP includes,
 > >records (structs), multi-structs, and arrays, along with the
 > >simple types
 > >from XML Schema Datatypes.  RPC calls and responses can be represented
 > >using any encoding for the SOAP default data model."  Then in
 > >chapter 5,
 > >you describe the default data model, and say "to promote
 > >interoperability,
 > >SOAP provides a standard encoding for the default data model (which is
 > >essentially the one we've had in chapter 5 all along).
 >
 > I like the separation of the datamodel from the serialization!
 >
 > Regarding the choice between A and B, the deciding factor between the
 > two seems to me to be whether the RPC convention has a requirement to
 > the underlying datamodel of supporting rooted graphs or not. I would say
 > that the SOAP data model does support rooted graphs and that the current
 > section 5 serialization uses the "root" attribute for this purpose but
 > other serializations are possible. Does that match your understanding?
 >
 > On the matter of naming a datamodel, while it certainly is possible to
 > have multiple serializations of a data model, do you also expect that we
 > are likely to have multiple data models for a single serialization? In
 > other words, do you think a given value for the encodingStyle attribute
 > will unambiguously identify not only the serialization but also the data
 > model, or do you think the two are separate?
 >
 > Henrik
 >
Received on Monday, 6 August 2001 17:33:15 GMT

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