Formal Objection re: Lack of MustUnderstand on EPRs

 
Hi all:

Currently there is no processing model for EPR extensions, and the core
spec says specifically that a processor will ignore any extensions which
it does not recognize or understand [1].  This means that there is no
way for the minter of an EPR to express any kind of mandatory extension,
which has serious consequences in the areas of versioning, policy, and
the scope of possible extensions - it's hard to design/use a meaningful
extension if you have no assurance it's not going to be ignored.

Some example use-cases that are not adequately supported can be found in
[2].

We feel that the decision not to include a "mustUnderstand" or
"required" attribute and a simple processing model (i.e. "don't use the
EPR if you don't understand an extension marked mandatory") was a
serious mistake which should be rectified.  It's a simple thing to add,
it is very much in line with Web Services patterns (c.f. SOAP
"MustUnderstand" and WSDL "required") and would enable many usage
scenarios which are currently impossible.

To be clear, what we are proposing would be a) the addition of a
"wsa:required" attribute, which would be allowed on all immediate
children of an endpointReference and all immediate children of the
<metadata> element, and b) a description of the rules associated with
this attribute.

Thanks,
  Glen Daniels, Sonic Software
  Anish Karmarkar, Oracle Corporation
  David Orchard, BEA Systems
  Rebecca Bergersen, IONA
 

[1]
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html
?content-type=text/html;%20charset=utf-8#eprextensibility
[2]
http://www.w3.org/mid/80A43FC052CE3949A327527DCD5D6B27011FA76A@MAIL01.be
dford.progress.com

Received on Tuesday, 19 July 2005 18:17:37 UTC