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

Re: An analysis of mustUnderstand and related issues

From: <Noah_Mendelsohn@lotus.com>
Date: Mon, 14 May 2001 10:22:50 -0400
To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
Cc: xml-dist-app@w3.org
Message-ID: <OFC1777B40.1145F3A0-ON85256A4C.004EB0B9@lotus.com>
Jean-Jacques Moreau writes:

>>  So we would not be able to express 
>> "headerA OR headerB" ? (That's
>> fine; just wondering.)

Right, in this proposal.  I tried to indicate that among the many reasons 
to be suspicious of this proposal is that it indeed heads one down the 
slippery slope leading to, for example, a Turing-complete language for 
expressing dependency rules.  I don't think we want to go there.  If we 
think that a simpel facility like this hits an 80/20 or 90/10 point, then 
I think it's interesting to consider.  If not, I don't think we should try 
it at all.

>> I think you need an additional bullet 
>> that says that a given actor processes 
>> headers according to the dependency graph

I understand where you're going with this, but I'm a bit less sure than 
you are that this is appropriate.  I am a little reluctant to get into 
"telling an actor what to do."  I think that characterizing "an actor" is 
difficult.  Clearly, in practice, some SOAP processors will use the 
dependency order as a dispatching hint, and in other cases it forms an 
often-useful crosscheck.  On the other hand, a given piece of software may 
simultaneously serve the role of several actors ("next" is the most 
obvious example, but users might create their own).  I don't think we 
should call out dependency processing specially on a per-access basis.

>> And I guess it is possible to impose 
>> dependencies on multiple headers
>> destined at different actors?


Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Monday, 14 May 2001 10:27:43 UTC

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