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/