Re: summary of soapbuilders discussion about inlining multirefs

> 3) For illustration of the problem .. There are two
> possible solutions:

This is a general problem and is not specific to references. Here is a third
possible solution that addresses the general problem - specify co-occurrence
constraints

Co-occurrence constraints,

(a) href | xsi:nil | xsi:type | SOAP-ENC:arrayType - only one of these
attributes must be present
(b) id must not be present if href or xsi:nil is present
(c) SOAP-ENC:offset must not be present if href, xsi:nil or xsi:type is
present

Regards, Asir

----- Original Message -----
From: "Jacek Kopecky" <jacek@idoox.com>
To: <xml-dist-app@w3.org>
Sent: Friday, October 19, 2001 8:21 AM
Subject: ETF: summary of soapbuilders discussion about inlining multirefs


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
recommendable.
 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
problem.
 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
solutions:
 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

                            Idoox
                            http://www.idoox.com/


[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 Tuesday, 30 October 2001 11:25:17 UTC