W3C home > Mailing lists > Public > public-ws-addressing-comments@w3.org > May 2007

[Fwd: LC ISSUE: Extensibility as per WSP section 4.5]

From: David Hull <dmh@tibco.com>
Date: Tue, 15 May 2007 11:28:07 -0400
Message-ID: <4649D187.2080106@tibco.com>
To: public-ws-addressing-comments@w3.org
(Forwarded from discussion list)

attached mail follows:

>From the discussion of LC136, it appears that there may be cause in the
future to extend our policy assertions, and that this could plausible
happen in more than one way.  Section 4.5 of WSP states that "Because
the set of behaviors indicated by a policy alternative depends on the
domain-specific semantics of the collected assertions, determining
whether two policy alternatives are compatible generally involves
domain-specific processing."

In particular, this means that if an alternative contains any of our
assertions, those assertions may participate in domain-specific processing.

Do we need to make any statement concerning such participation?

For example, we could state (though I doubt it would be wise) that our
assertions are only compatible with themselves and that any other
assertions appearing in an alternative with them MUST NOT be considered
compatible with them for intersection purposes.

This would prohibit, say, <All><wsam:Addressing><wsme:MyAssertion></All>
from being compatible with <All><wsam:Addressing></All>.

I think the best approach is to explicitly leave the door open for
anything, along the lines of:

    Other specifications may define additional assertions to be used in
    alternatives along with those defined here, or in policies nested
    within the assertions defined here.  This specification places no
    constraints on the domain-specific processing of such assertions or
    on the compatibility, or lack thereof, of such assertions with those
    defined here.

As this explicitly makes the least constraining statement possible, I do
not believe it would cause a breaking change.
Received on Tuesday, 15 May 2007 15:28:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:53 UTC