i0018: Protocol-specific markup in RefP's

Hey addressers:

Issue 18 is about a situation like this:

<epr>
 <refp>
   <someHeader soap11:mustUnderstand="true"
               soap11:actor="http://actor1"/>
 </refp>
</epr>

The current spec states that rep's are to be bound directly to SOAP
headers.  So in the above case, this would work fine if bound to SOAP
1.1, but not if bound to SOAP 1.2 (in the latter case, the namespace
would need to change, and the "actor" attribute would need to change to
"role").  The issue is that refp's in these kinds of situations break
the abstraction boundary between the abstract properties and the
particular binding.

My proposal for this issue would be the same as that for issue 008 - if
there were some kind of container header for refp's instead of making
each refp a header itself, this problem would disappear.  That said,
alternate solutions might include:

* Don't allow SOAP markup in refp's at all

* Introduce abstract wsa:mustUnderstand/wsa:role/etc attributes,
  which bind to the appropriate SOAP constructs (and something
  else for other bindings?)

* Remain silent on this and let people shoot themselves in
  the foot if they so choose

The container option continues to seem the most logical and simple to
me, as I have not yet seen a compelling use-case for making refp's
individual headers.  Interestingly, the argument that I have heard which
says that "using the SOAP processing model" is a good reason to keep
refp's as individual headers seems to exascerbate this particular issue
- if indeed we want to use the SOAP processing model for refp's (which I
don't buy yet), it seems logical that we would therefore want to specify
things like mustUnderstand, actor/role, and relay on our refp's.  If so,
we run into this problem - and what happens when we bind directly to
HTTP, anyway?

Thoughts?

Thanks,
--Glen

Received on Monday, 15 November 2004 17:30:32 UTC