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

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

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Wed, 10 Jan 2001 10:47:39 -0800
Message-ID: <01cc01c07b35$cf7d4370$308f3b9d@redmond.corp.microsoft.com>
To: "Hugo Haas" <hugo@w3.org>, "Noah Mendelsohn" <Noah_Mendelsohn@lotus.com>
Cc: "Martin Duerst" <duerst@w3.org>, <xml-dist-app@w3.org>
I think 2 is a good question - I can't think of any ;)

In 3, what is the difference between

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

and

      <m:logic xmlns:m="http://logicsRus.org xp:mustUnderstand>
        <m:or>
          <m:operand href="auth1" />
          <m:operand href="auth2" />
        </m:or>
      </m:logic>

One reason why I think this quickly leads to complexity is when we deal with
fault messages. If sender A says

    A: I want you to do (L or M) and N

then the receiver B might say

    B: I do not understand L
       I do understand M as well as N but not the two in conbination
       I do understand P in combination with M
       I do understand N by itself

Another reason is that somebody would have to make the decision that L and M
are substitutable so that it is ok for the server to pick either L or M. This
can be done within specific domains and contexts but is hard without a
context. What if M is not an authentication module but a payment module? How
would the server find out that M and L are in fact substitutable?

I don't think we would want this to be grokked by XP. On the other hand,
it would seem possible to build this on top of XP as the single
optional/mandatory means that we always have a well-defined processing
model at the core.

Henrik

> 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.
Received on Wednesday, 10 January 2001 13:48:14 GMT

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