RE: Language for Reference Parameters

Dear Paco,

Many thanks for the explanation! I personally agree with the opaque
semantics of EPRs. However, I would have expected that a normative
'SHOULD' could have been used as a guidance to the WS community without
preventing sub-communities from defining conventions which break the
opaqueness, in a similar way to how query strings in URIs are usually
(mis)used by clients. 

Having said that, I accept your view and current wording and will not
insist on this (especially given the more important issues which the
group has to address at this late stage).

Best regards,
--
Savas Parastatidis
http://savas.parastatidis.name
 

> -----Original Message-----
> From: Francisco Curbera [mailto:curbera@us.ibm.com]
> Sent: Tuesday, April 26, 2005 6:58 PM
> To: Savas Parastatidis
> Cc: humphrey@cs.virginia.edu; public-ws-addressing@w3.org; public-ws-
> addressing-request@w3.org; wasson@virginia.edu
> Subject: Re: Language for Reference Parameters
> 
> The rationale behind those words is to protect client code from
possible
> changes in EPRs introduced by the issuer. The idea is that client code
is
> more robust if it is built in such a way that it takes no dependency
on
> the
> specific values, schema or overall structure of the reference
parameter
> elements.
> 
> On the other hand, there is no way (and probably no reason) to prevent
> specific communities from defining ad-hoc conventions about the
> information
> that these elements carry. This is very similar to the URI opaqueness
> property: an architectural principle that is often violated for
various
> (sometimes legitimate) reasons.
> 
> Given that, I don't think anything like a MUST or a SHOULD is
appropriate,
> since it would just prevent the normal development of perfectly good
usage
> scenarios and likely end up confusing everyone (the WG itself spent a
lot
> of time debating the consequences of those words for example).
> 
> Paco
> 
> 
>

Received on Tuesday, 26 April 2005 19:13:22 UTC