- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Wed, 28 May 2003 10:43:40 -0700
- To: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
- Cc: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
When the swa:doInclude header is invoked by the SOAP processing model, all further processing must take place as if each xbinc:Include element present in the message had been replaced by the representation obtained by dereferencing the URI contained in its href attribute, after a canonical base64 transformation is performed. A naïve implementation may replace the message infoset with the post-Include infoset and continue processing. A more sophisticated implementation may internally manage when inclusion is performed, as long as any forwarded infoset (that is, any that leaves the domain of control of that implementation) is complete and valid. Because PASWA is able to change the serialization of arbitrary message parts, the doInclude header must set soap:mustUnderstand to true. Negotiation and discovery of the capabilities of individual SOAP nodes with regards to PASWA functionality is outside the scope of this proposal; it may be effected through an out-of-band agreement, WSDL extension, or other mechanism. Determining of the order of processing in relation to other SOAP header blocks is out of scope for this proposal; it may be negotiated by an out-of-band agreement or other mechanism. An intermediary may forward a SOAP message with new or changed portions marked for PASWA processing; determination of what portions are eligible for this serialization may happen by means such as: - explicit instructions in a Header Block - use of available type information - nomination of an attribute that indicates candidate(s) for serialization (n.b.; this attribute must be present when the message is signed, in the case where digital signatures are used). Specification of any one mechanism for this functionality is out of scope for this proposal. -- Mark Nottingham
Received on Wednesday, 28 May 2003 13:43:51 UTC