Re: An analysis of mustUnderstand and related issues

	> From: Noah_Mendelsohn@lotus.com
	> To: Mark Jones <jones@research.att.com>
	> Cc: moreau@crf.canon.fr, xml-dist-app@w3.org
	> Subject: Re: An analysis of mustUnderstand and related issues
	> Date: Tue, 15 May 2001 11:13:53 -0400

	> Mark Jones writes:

	> >> I also wondered about disjunction. 

	> I agree, it's potentially useful.  I think the overall XML experience 
	> teaches us to be very reluctant about adding complexity, even if the 
	> function provided seems "useful".  Indeed, the most obvious criticism of 
	> my proposal as it stands is that even the function it does provide has not 
	> been shown to meet that 80/20 or value/simplicity cut.  The concern I have 
	> about the additional complexity of supporting disjunctions is that it 
	> rapidly leads to at least predicate logic, and maybe a full programming 
	> language.  Can I do a full:

	>         <SOAP-ENV: Header SOAP-ENV:dependsOn="( (AND (OR A B C )  D  (OR E 
	> F)))"/>  ?

	> (and yes, we would probably want to use full markup, as you suggest).  Do 
	> we allow full Turing-complete computation? 

	> Now, that's not necessarily a bad thing, but it's significantly more 
	> complexity in SOAP processors, harder to write tools that reason about 
	> what's happening, etc., harder for users to grok, etc.  Also:  at some 
	> point you want to tie this stuff into higher level flow management systems 
	> such as WSFL [1]. 

Actually, I wasn't proposing that disjunction, exactly-one-of, or any
particular logical extensions be mandated.  I think we can add these
facilities as a (perhaps broadly standard) module.  [I think of it as
the "logic" module, or "constraints", or "control".)  This puts no
obligatory complexity into a SOAP processor.  People would be free to
invent their own constraint modules, although there could be a basic,
default one.  An extensible, module approach would let the appropriate
level of expressive power for contraints be decided by the
marketplace.


	> So, my recommendation is that we do indeed consider the proposal for 
	> disjunctions, but that we set the bar reasonably high on actually agreeing 
	> to mandate it.  Thank you.

Right.  I'm not for mandating it.  In fact, we can even possibly get
by without even mandating conjunction!  (Discussed toward the end,
below.)

In my prior note, by the way, I did not mean to mark the blocks A and
B with mustUnderstand="true".  Only the disjunction constraint header,
C, should be marked with mustUnderStand="true".  You do need an
attribute in blocks A and B to ensure that a replacement block will be
supplied to indicate successful understanding and processing, so that
other blocks (C) can check it.  I called it "markHappened".  The main
import of marking a block "markHappened" would be the guarantee that
we get a replacement block with the same ID that has a
SOAP_ENV:hasHappened="true" attribute if it is processed and properly
understood.

So for disjunction, the example should have been:

   <SOAP-ENV:Header ID="A"
       SOAP-ENV:Actor="uriA"
       SOAP-ENV:markHappened="true">
     <nsa:DoThisForA xmlns:nsa="http://nsa.gov/uriA">
     ...
     </nsa:DoThisForA>
   </SOAP-ENV:Header>

   <SOAP-ENV:Header ID="B"
       SOAP-ENV:Actor="uriB"
       SOAP-ENV:markHappened="true">
     <nsb:DoThisForB xmlns:nsb="http://nsb.gov/uriB">
     ...
     </nsb:DoThisForB>
   </SOAP-ENV:Header>

   <SOAP-ENV:Header ID="C"
       SOAP-ENV:Actor="uriLogic"
       SOAP-ENV:mustUnderstand="true"
      <logic:Or xmlns:logic="http://logic.gov/logic">
         <logic:CheckHasHappened href="A"/>
         <logic:CheckHasHappened href="B"/>
      </logic:Or>
   </SOAP-ENV:Header>


You could take the same general approach with conjunction.  If we went
this route, we wouldn't have to mandate anything in terms of the
constraint language, including conjunction.  Note also that just as
with the disjunction case above, you only need a "markHappened"
attribute on blocks A and B The conjunctive block C will ensure the
constraint, so you don't need a mustUnderstand attribute on blocks A
or B (but it won't hurt).

   <SOAP-ENV:Header ID="A"
       SOAP-ENV:Actor="uriA"
       SOAP-ENV:markHappened="true"
     <nsa:DoThisForA xmlns:nsa="http://nsa.gov/uriA">
     ...
     </nsa:DoThisForA>
   </SOAP-ENV:Header>

   <SOAP-ENV:Header ID="B"
       SOAP-ENV:Actor="uriB"
       SOAP-ENV:markHappened="true"
     <nsb:DoThisForB xmlns:nsb="http://nsb.gov/uriB">
     ...
     </nsb:DoThisForB>
   </SOAP-ENV:Header>

   <SOAP-ENV:Header ID="C"
       SOAP-ENV:Actor="uriLogic"
       SOAP-ENV:mustUnderstand="true"
      <logic:And xmlns:logic="http://logic.gov/logic">
         <logic:CheckHasHappened href="A"/>
         <logic:CheckHasHappened href="B"/>
      </logic:And>
   </SOAP-ENV:Header>

You still need a "dependsOn" attribute to represent conditional
dependence for executing a header.  The syntax could be simplified to
reference a single block if you did conjunction in the same way as
other constraints (above).  Alternatively, your proposal which allows
conjunction might be a convenient syntactic shorthand for the common
conjunctive case.  Here is a block D whose processing depends on C,
which represents the successful conjunction of blocks A and B:

   <SOAP-ENV:Header ID="D"
       SOAP-ENV:Actor="uriD"
       SOAP-ENV:mustUnderstand="true"
       SOAP-ENV:dependsOn="C"
     <nsd:DoThisForD xmlns:nsd="http://nsb.gov/uriD">
     ...
     </nsd:DoThisForD>
   </SOAP-ENV:Header>


--mark

Mark A. Jones
AT&T Labs - Research
Shannon Laboratory
Room A201
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
  fax: (973) 360-8970


	> [1]  http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

	> ------------------------------------------------------------------------
	> Noah Mendelsohn                                    Voice: 1-617-693-4036
	> Lotus Development Corp.                            Fax: 1-617-693-8676
	> One Rogers Street
	> Cambridge, MA 02142
	> ------------------------------------------------------------------------

Received on Tuesday, 15 May 2001 15:24:23 UTC