- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Mon, 3 Jan 2005 10:38:13 -0500
- To: Hugo Haas <hugo@w3.org>
- Cc: public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
- Message-ID: <OF208B4DE0.E9B8B036-ON85256F7E.00551145-85256F7E.0055E21D@us.ibm.com>
Hugo,
I am almost ok with the text you propose; I would like to keep an explicit
reference to the possibility of embedded metadata becoming stale. So I
would like to propose that the last two paragraphs in your proposed text be
amended as follows:
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. Moreover, while embedded metadata is
necessarily valid at the time the EPR is initially created it may become
stale at a later point in time.
To deal with conflicts between the embedded metadata of two EPRs, or
between embedded metadata and metadata obtained from a different source, or
to ascertain the current validity of embedded metadata, mechanisms that are
outside of the scope of this specification, such as EPR life cycle
information [link to section 2.4 Endpoint Reference Lifecycle] or retrieval
of metadata from an authoritative source, SHOULD be used.
Paco
Hugo Haas <hugo@w3.org>
Sent by: To: public-ws-addressing@w3.org
public-ws-addressing-req cc:
uest@w3.org Subject: i014 - Metadata Update/Reconciliation: a proposal
12/15/2004 08:37 AM
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/
#### signature.asc has been removed from this note on January 03, 2005 by
Francisco Curbera
Attachments
- application/octet-stream attachment: signature.asc
Received on Monday, 3 January 2005 15:38:48 UTC