Re: i014 - Metadata Update/Reconciliation: a proposal

  If two different client applications are given the same EPR (same w.r.t. 
address and ref.props) can we really assume they have the same 
metadata/wsdl.... ?  As an example, what if based on the client's 
permissions the WSDL for a particular endpoint will differ - perhaps one 
has Admin access and the other doesn't.  In this case can WSA really claim 
that the two EPRs are the same w.r.t. metadata/WSDL and messages they 
accept? No.  It seems to me that there are lots of factors that may 
influence the metadata associated with an EPR and WSA can't possibly take 
them all into account.  Therefore, I question whether WSA can make any 
claim about two EPRs being the same or not for this purpose. 
  However, there are cases where comparing EPRs does make sense and WSA 
does have a role.  Take an example of a pub-sub engine with registrations 
(registration EPRs) it manages.  Comparing EPRs for the purpose of knowing 
which EPR should be removed from the sub-list does make sense to me.  In 
this case, WSA saying that it should compare the address and ref.props 
(ignoring diffs in ref.params) is a valid thing for WSA to define.
-Dug




Hugo Haas <hugo@w3.org> 
Sent by: public-ws-addressing-request@w3.org
12/15/2004 08:37 AM

To
public-ws-addressing@w3.org
cc

Subject
i014 - Metadata Update/Reconciliation: a proposal






This email starts discussion of issue i014 and proposes a resolution.

The issue description is:

  Do we provide a way to determine the precedence and relationship of
  existing metadata to that given in an EPR, in a generic fashion? If
  so, what? The Member submission talks about policy precedence in
  section 2.4; should that remain/be expanded upon?

Discussion of the issue started at this week's call:

    http://www.w3.org/2002/ws/addr/4/12/13-ws-addr-minutes.html#item05

The specification says that EPRs with identical [address]/[reference
properties] pair represent endpoints that accept the same messages and
have identical metadata. It also says that an application receiving
EPRs with different [address]/[reference properties] should assume
that the endpoints represented accept different messages and have
different metadata.

This issue came to be by considering the following text about EPR
comparison[2]:

  In particular, the policies applicable to the two endpoints are the
  same regardless of the values of any embedded [policies]. Embedded
  policies are not authoritative and may be stale or incoherent with
  the policies associated with the endpoint.

I believe that the above text is confusing because embedded [policies]
for the same [address]/[reference properties] pair may differ for
valid reasons, as EPRs may not contain the full policy for the
endpoint, and the above text does not make it clear.

There was some agreement on Monday's call around the idea that
metadata for the same referred endpoint MAY be different in two
different EPRs. Also, in case of conflicts, I think that the
arbitration is out of scope for us as it is a conflict like any other,
e.g. "I got two WSDL documents for a service from the Web that contain
contradicting information, what do I do?"

I would therefore propose that we replace the following text in
section 2.3:

   The following rules clarify the relation between the behaviors of the
   endpoints represented by two endpoint references with the same 
[address]
   and the same [reference properties].

     * The two endpoints accept the same sets of messages, and follow and
       require the same set of policies. That is, the XML Schema, WSDL, 
and
       policy metadata applicable to the two references are the same.

     * In particular, the policies applicable to the two endpoints are the
       same regardless of the values of any embedded [policies]. Embedded
       policies are not authoritative and may be stale or incoherent with
       the policies associated with the endpoint.

by the following more general statement which applies to more than
[policies]:

   The following rules clarify the relation between the behaviors of the
   endpoints represented by two endpoint references with the same 
[address]
   and the same [reference properties].

   The two endpoints accept the same sets of messages, and follow and
   require the same set of policies. That is, the XML Schema, WSDL,
   and policy and other metadata applicable to the two references are
   the same.

   However, the metadata embedded in each of the EPRs MAY differ, as
   the metadata carried by an EPR is not necessarily a complete
   statement of the metadata pertaining to the endpoint.

   In case the embedded metadata of an EPR conflicts with the embedded
   metadata of another equivalent EPR, i.e. an EPR having the same
   [address] and [reference properties] properties, or with metadata
   for the referred endpoint obtained from another source, mechanisms
   that are outside of the scope of this specification, such as EPR
   life cycle [link to section 2.4 Endpoint Reference Lifecycle] or
   retrieving metadata from an authoritative source, SHOULD be used to
   resolve the conflict.

I think that this would address issue i014 by not defining any
precedence rules and clarifying when there is conflict or not.

Comments?

Regards,

Hugo

  2. 
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html#eprcomp

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
[attachment "signature.asc" deleted by Doug Davis/Raleigh/IBM]