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

[R700b] Optional/mandatory bit (was: Comments on XML Protocol Reqs)

From: Hugo Haas <hugo@w3.org>
Date: Wed, 10 Jan 2001 18:41:35 +0100
To: Noah_Mendelsohn@lotus.com
Cc: Martin Duerst <duerst@w3.org>, frystyk@microsoft.com, xml-dist-app@w3.org
Message-ID: <20010110184134.H5342@home.larve.net>
On Sat, Jan 06, 2001, Noah_Mendelsohn@lotus.com wrote:
> >> I think that it is more a simplicity problem. An
> >> optional/mandatory bit is easy to define; a combination of and's
> >> and or's is more complex to represent and process.
> 
> Like Martin, I agree with what Hugo has written, but I think there
> is a perspective from which one can even more strongly support
> Hugo's case that a single mustUnderstand is an effective trade-off:

I was not really advocating for a single mustUnderstand.

I was just pointing out that Martin's comment had to be considered
from a simplicity point of view.

> The nature of an extension must be clearly identified.  In SOAP extensions 
> are identified by a URI name, and we may reasonably expect a similar 
> mechanism for XP.  mustUnderstand on a header signals that the recipient 
> must "understand" the significance of the extension, not necessarily that 
> it must blindly choose any particular means of dealing with it.  So, I 
> claim that it may be in the nature of "understanding" header "B" to 
> realize that it obviates the need to do any explicit processing on header 
> "A", even if A itself is marked mustUnderstand. 
> 
> Consider two extensions I will call "stronglyAuthenticate" and 
> "weaklyAuthenticate", with the former marked mustUnderstand.
[..]
> I am not trying to say that one cannot conjure up sensible use cases for 
> which some sort of combinatorial  logic might be useful, just trying to 
> strengthen the argument for a simple mustUnderstand as a reasonable 80/20 
> trade-off that covers a lot of of interesting situations.

I think that we should consider:

1. how much more complex XP would be with an and/or combination of
  extensions that must be understood.

  Reusing your example, we could imagine something like:

    <xp:XP>

       <xp:mustUnderstand type="or">
         <xp:operand ref="auth1" />
         <xp:operand ref="auth2" />
       </xp:mustUnderstand>

       <xp:Header>
         <wa:authenticate xlmns:wa="...uri for weak auth header..."
                          xp:hid="auth1">
           ...
         </wa:authenticate>
       </xp:Header>

       <xp:Header>
         <sa:authenticate xlmns:sa="...uri for strong auth header..."
                          xp:hid="auth2">
           ...
         </sa:authenticate>
       </xp:Header>

       ... body here...

    </xp:XP>

  to indicate that the receiver must understand either
  weakAuthentication or strongAuthentication.

2. how many scenarios would be impossible with a single
  optional/mandatory bit.

  I think that it is difficult to forecast how many cases would be
  compromised. Sending out headers for 2 authentication schemes and
  having only one supported by the receiver could be not so uncommon.

3. if we go for an optional/mandatory bit solution, what would be the
  cost of enabling more complex conditions later if we need them.

  That could be handled by an XP module.

-- 
Hugo Haas - W3C/MIT
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092
Received on Wednesday, 10 January 2001 12:41:41 GMT

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