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

ETF: summary of soapbuilders discussion about inlining multirefs

From: Jacek Kopecky <jacek@idoox.com>
Date: Fri, 19 Oct 2001 15:21:37 +0200 (CEST)
To: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0110191435450.10130-100000@mail.idoox.com>
 Hi all. 8-)
 Here is the summary of the discussion on soapbuilders [1] about
inlining multirefs, which could solve the issue #18 (and #121).
 There was a general agreement that allowing inlining the
referenced data would be good.
 There were various points that people were pointing out:
 1) maybe we should also disallow forward references
 2) referencing data that can be stripped out from the message
 3) attribute clashes on references

 Now let me detail the points.
 1) Some people felt forward references might be bad, other felt
my original proposal disallowed forward references. I propose to
keep forward references because they allow references from
headers to body, which might be necessary for things like
XMLDSIG, although any other referencing mechanism (most probably
XML IDREF) could be used instead of SOAP Encoding referencing.

 2) References from body to headers and references among headers
may lead to situations where the referenced data is removed from
the message. There are a few possible solutions to this (I'm not
saying the list is necessarily complete):
 a) Rely on application designers to do it right. This is not
 b) disallow references between "serialization trees", the roots
of "serialization trees" being each header block and the Body (or
for the sake of symmetry each body block, but this is not
necessary to solve problem 2). If we go this way we must allow
for e.g. the dig-sig header to point to anything using different
means from SOAP Encoding hrefs.
 c) "References in which the referenced data may disappear before
all the references (i.e. references between headers or a header
and the body), MUST be serialized as "independent" elements in
the <soap-env:Header/> element and they must contain an attribute
'actor' with the value '.../none'. All other referenced data
SHOULD be serialied in-line." Quite complex but solving the
 Personally, I prefer b) over c) over a).

 3) For illustration of the problem:
	<a foo="bar" id="1">blah</a>
	<b foo="baz" href="#1"/>
The problem is what is the value of b? There are two possible
 a) merge attributes - prefer those from the accessor over those
from the referenced element,
 b) ignore attributes on the accessor except for a limited list
of exceptions: href, enc:position. (Might want to add actor and
mustUnderstand, but see my reasons against it in [2]).
 I recommend b), because of reasons in [3].

 If any of my recommendations needs more discussion, let me know
which and I'll write a separate email so that a formal issue can
be formed, for it's better when an the issue list entry links to
a message with a single issue. 8-)

 Best regards,

                            Jacek Kopecky


[1] http://groups.yahoo.com/group/soapbuilders/message/5557
[2] http://groups.yahoo.com/group/soapbuilders/message/5591
[3] http://groups.yahoo.com/group/soapbuilders/message/5580
Received on Friday, 19 October 2001 09:21:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:40 UTC