Should a JAX-WS handler ever see the XOP infoset? The spec does not clarify this, and the RI seems to have contradicting behavior (outbound messages are prevented from being xop encoded if there is a handler, inbound messages are left as is).
Since the XOP specification mentions that conceptual form is an XML infoset with base64 elements, it seems that the correct behavior is that a handler should not see the XOP infoset. This is especially important when using encryption and/or signature processing.
If it is clarified and decided that JAX-WS handlers should see the conceptual XML infoset, then this raises two other questions:
1. Should attachments still be visible as AttachmentPart(s) on SOAPMessage?
- It would be more efficient to leave them, however this introduces
a consistency problem. For example, technically a handler has the
ability to update either the base64 value or the attachment itself.
2. Should XOP processing still be done, but this time after handlers are processed?
From the specs (http://www.w3.org/TR/xop10/):
However, at the conceptual level, this binary data can be thought of as being base64-encoded in the XML Document. As this conceptual form might be needed during some processing of the XML Document (e.g., for signing the XML document), it is necessary to have a one to one correspondence between XML Infosets and XOP Packages. Therefore, the conceptual representation of such binary data is as if it were base64-encoded, using the canonical lexical form of XML Schema base64Binary datatype (see [XML Schema Part 2: Datatypes Second Edition] 3.2.16 base64Binary). In the reverse direction, XOP is capable of optimizing only base64-encoded Infoset data that is in the canonical lexical form.
Looking at the above statement I'd say a handler should see the conceptual level, that is the base64 representation without an actual attachment visible at the message level. It's arguable though if a handler needs mutable access to that data.
The question was sent to the JAX-WS list, since this is a deficiency of the spec.