AddXml (HttpRequest subroutine): Difference between revisions
m (→Usage notes) |
m (→Usage notes) |
||
Line 10: | Line 10: | ||
<table class="syntaxTable"> | <table class="syntaxTable"> | ||
<tr><th>%httpreq</th> | <tr><th>%httpreq</th> | ||
<td>A previously defined and instantiated HTTPRequest object. | <td>A previously defined and instantiated <var>HTTPRequest</var> object. | ||
</td></tr> | </td></tr> | ||
<tr><th>%xmldoc</th> | <tr><th>%xmldoc</th> | ||
Line 19: | Line 19: | ||
<ul> | <ul> | ||
<li><b>AllowXmlDecl</b> or <b>NoXmlDecl</b> | <li><b>AllowXmlDecl</b> or <b>NoXmlDecl</b> | ||
AllowXmlDecl, the default, produces the XML declaration (that is, <?xml&thinsp.version=...?>) if the declaration was already defined in ''%xmldoc''. NoXmlDecl omits the XML declaration. | AllowXmlDecl, the default, produces the XML declaration (that is, <?xml&amp;thinsp.version=...?>) if the declaration was already defined in ''%xmldoc''. NoXmlDecl omits the XML declaration. | ||
<li><b>Indent</b> <i><b>n</b></i> | <li><b>Indent</b> <i><b>n</b></i> | ||
The display of each lower level in the serialized subtree is indented ''n'' spaces from the previous level's starting point, where <i>n</i> is a non-negative integer. | The display of each lower level in the serialized subtree is indented ''n'' spaces from the previous level's starting point, where <i>n</i> is a non-negative integer. | ||
Line 47: | Line 47: | ||
This indicates that namespace declarations (based on the prefix being declared) and attributes (based on the namespace URI followed by the local name) are serialized in sorted order. This can be useful, for instance, to serialize a portion of an XML document for a signature. | This indicates that namespace declarations (based on the prefix being declared) and attributes (based on the namespace URI followed by the local name) are serialized in sorted order. This can be useful, for instance, to serialize a portion of an XML document for a signature. | ||
The sort order for namespace declarations and attributes is from lowest to highest, and it uses the Unicode code ordering (for example, numbers are lower than letters). | The sort order for namespace declarations and attributes is from lowest to highest, and it uses the Unicode code ordering (for example, numbers are lower than letters). | ||
This option was added in <var class="product">Sirius Mods</var> version 6.9 as a step towards support for canonicalization. As of version 7.0, comprehensive support for canonicalized serialization is provided (only) by the Serial method ExclCanonical option, described in the [[Janus SOAP Reference Manual]]. SortCanonical is described in greater detail at the end of &ldquo;Usage notes,&rdquo; below. </ul> | This option was added in <var class="product">Sirius Mods</var> version 6.9 as a step towards support for canonicalization. As of version 7.0, comprehensive support for canonicalized serialization is provided (only) by the Serial method ExclCanonical option, described in the [[Janus SOAP Reference Manual]]. SortCanonical is described in greater detail at the end of &amp;ldquo;Usage notes,&amp;rdquo; below. </ul> | ||
</td></tr></table> | </td></tr></table> | ||
Line 59: | Line 59: | ||
<li>As of <var class="product">Sirius Mods</var> version 6.6, if you do not explicitly set a | <li>As of <var class="product">Sirius Mods</var> version 6.6, if you do not explicitly set a | ||
content-type HTTP request header via <var>[[AddHeader (HTTPRequest subroutine)|AddHeader]]</var>, | content-type HTTP request header via <var>[[AddHeader (HTTPRequest subroutine)|AddHeader]]</var>, | ||
AddXml generates a content-type header of “text/xml” upon a Post. | AddXml generates a content-type header of &ldquo;text/xml&rdquo; upon a Post. | ||
To suppress this automatic header generation, you can set the | To suppress this automatic header generation, you can set the | ||
<var>[[AutoSendXMLContentType (HTTPRequest property)|AutoSendXMLContentType]]</var> property | <var>[[AutoSendXMLContentType (HTTPRequest property)|AutoSendXMLContentType]]</var> property | ||
Line 93: | Line 93: | ||
These character references are used: | These character references are used: | ||
<table> | <table> | ||
<tr><th>tab</th><td>&#x9; | <tr><th>tab</th><td>&amp;#x9; | ||
</td></tr> | </td></tr> | ||
<tr><th>CR</th><td>&#xD; | <tr><th>CR</th><td>&amp;#xD; | ||
</td></tr> | </td></tr> | ||
<tr><th>LF</th><td>&#xA; | <tr><th>LF</th><td>&amp;#xA; | ||
</td></tr></table> | </td></tr></table> | ||
The EBCDIC and corresponding ASCII encodings of the characters is: | The EBCDIC and corresponding ASCII encodings of the characters is: | ||
<table> | <table> | ||
<tr><th> </th> | <tr><th>&nbsp;</th> | ||
<th>EBCDIC</th> | <th>EBCDIC</th> | ||
<th>ASCII</th></tr> | <th>ASCII</th></tr> | ||
Line 139: | Line 139: | ||
Comments: | Comments: | ||
<ul> | <ul> | ||
<li>The reason for the name (<var>SortCanonical</var>) is that this ordering is part of the specification of the <i><b>Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&hyph.c14n) and the <i><b>Exclusive Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&hyph.exc&hyph.c14n), which constrain serializations to facilitate processing such as digital signatures. | <li>The reason for the name (<var>SortCanonical</var>) is that this ordering is part of the specification of the <i><b>Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&hyph.c14n) and the <i><b>Exclusive Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&hyph.exc&hyph.c14n), which constrain serializations to facilitate processing such as digital signatures. | ||
<li>Notice the use of the <var>NoEmptyElt</var> option above. This produces an STag (<code><top ...></code>) and an ETag (<code></top></code>) for an empty element, rather than just the EmptyElemTag (<code><top ...></code>). | <li>Notice the use of the <var>NoEmptyElt</var> option above. This produces an STag (<code><top ...></code>) and an ETag (<code></top></code>) for an empty element, rather than just the EmptyElemTag (<code><top ...></code>). | ||
The canonical XML recommendations state that an STag/ETag pair, rather than an EmptyElemTag, is the serialization for an empty element. | The canonical XML recommendations state that an STag/ETag pair, rather than an EmptyElemTag, is the serialization for an empty element. | ||
Line 154: | Line 154: | ||
<li>As of <var class="product">Sirius Mods</var> version 6.6, if you do not explicitly set a | <li>As of <var class="product">Sirius Mods</var> version 6.6, if you do not explicitly set a | ||
content-type HTTP request header via <var>[[AddHeader (HTTPRequest subroutine)|AddHeader]]</var>, | content-type HTTP request header via <var>[[AddHeader (HTTPRequest subroutine)|AddHeader]]</var>, | ||
AddXml generates a content-type header of &ldquo;text/xml&rdquo; upon a Post. | AddXml generates a content-type header of &amp;ldquo;text/xml&amp;rdquo; upon a Post. | ||
To suppress this automatic header generation, you can set the | To suppress this automatic header generation, you can set the | ||
<var>[[AutoSendXMLContentType (HTTPRequest property)|AutoSendXMLContentType]]</var> property | <var>[[AutoSendXMLContentType (HTTPRequest property)|AutoSendXMLContentType]]</var> property | ||
Line 189: | Line 189: | ||
<table> | <table> | ||
<tr><th>tab | <tr><th>tab | ||
</th><td>&amp;#x9; | </th><td>&amp;amp;#x9; | ||
</td></tr> | </td></tr> | ||
<tr><th>CR | <tr><th>CR | ||
</th><td>&amp;#xD; | </th><td>&amp;amp;#xD; | ||
</td></tr> | </td></tr> | ||
<tr><th>LF | <tr><th>LF | ||
</th><td>&amp;#xA; | </th><td>&amp;amp;#xA; | ||
</td></tr></table> | </td></tr></table> | ||
The EBCDIC and corresponding ASCII encodings of the characters is: | The EBCDIC and corresponding ASCII encodings of the characters is: | ||
<table> | <table> | ||
<tr><th>&nbsp;</th> | <tr><th>&amp;nbsp;</th> | ||
<th>EBCDIC</th> | <th>EBCDIC</th> | ||
<th>ASCII</th></tr> | <th>ASCII</th></tr> | ||
Line 235: | Line 235: | ||
Comments: | Comments: | ||
<ul> | <ul> | ||
<li>The reason for the name (<var>SortCanonical</var>) is that this ordering is part of the specification of the <i><b>Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&hyph.c14n) and the <i><b>Exclusive Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&hyph.exc&hyph.c14n), which constrain serializations to facilitate processing such as digital signatures. | <li>The reason for the name (<var>SortCanonical</var>) is that this ordering is part of the specification of the <i><b>Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&amp;hyph.c14n) and the <i><b>Exclusive Canonical XML Recommendation</b></i> (http://www.w3.org/TR/xml&amp;hyph.exc&amp;hyph.c14n), which constrain serializations to facilitate processing such as digital signatures. | ||
<li>Notice the use of the <var>NoEmptyElt</var> option above. This produces an STag (<code><top ...></code>) and an ETag (<code></top></code>) for an empty element, rather than just the EmptyElemTag (<code><top ...></code>). | <li>Notice the use of the <var>NoEmptyElt</var> option above. This produces an STag (<code><top ...></code>) and an ETag (<code></top></code>) for an empty element, rather than just the EmptyElemTag (<code><top ...></code>). | ||
The canonical XML recommendations state that an STag/ETag pair, rather than an EmptyElemTag, is the serialization for an empty element. | The canonical XML recommendations state that an STag/ETag pair, rather than an EmptyElemTag, is the serialization for an empty element. |
Revision as of 22:42, 15 June 2011
Template:HTTPRequest:AddXML subtitle
This subroutine adds a Janus SOAP XmlDoc object instance to the HTTP Post data that is subsequently sent on a Post method invocation.
Syntax
Template:HTTPRequest:AddXML syntax
Syntax terms
%httpreq | A previously defined and instantiated HTTPRequest object. |
---|---|
%xmldoc | An XmlDoc object that contains an instantiated XmlDoc object. |
xmloptions | Any combination of the following options (but single occurrences only):
|
Usage notes
- The XmlDoc that is passed is serialized into the post data of the request being built. It is not required that you serialize the XmlDoc first.
- Invoking this method erases any post data previously added by AddXML or AddLongString method calls.
- As of Sirius Mods version 6.6, if you do not explicitly set a content-type HTTP request header via AddHeader, AddXml generates a content-type header of “text/xml” upon a Post. To suppress this automatic header generation, you can set the AutoSendXMLContentType property to False.
- The xmloptions may be specified in any case, for example, you can use
either
NoXmlDecl
ornoxmldecl
, interchangeably. - If one of the line-end
(
CR
,LF
,CRLF
) options or ifIndent
is specified, and an element to be serialized has thexml:space="preserve"
attribute, then within the serialization of that element and its descendants, no line-end (nor indentation) characters are inserted to provide readability. In addition, thexml:space="default"
attribute has no effect under these options: specified by itself, it does not influence serialization, nor does it cause resumption of readability line-ends or indents if they were suspended by a containingxml:space="preserve"
. - As of version 6.7, the AddXml method uses the
character references specified in the XML Canonicalization specification
(http://www.w3.org/TR/xml-c14n) to
display the following characters:
- For Attribute nodes: tab, carriage return, and linefeed
- For Text nodes: carriage return
Since the character references are not subject to the standard XML whitespace normalization (so not removed), a serialized document (or subtree) that is then deserialized will retain this whitespace.
These character references are used:
tab &#x9; CR &#xD; LF &#xA; The EBCDIC and corresponding ASCII encodings of the characters is:
EBCDIC ASCII tab X'05' X'09' CR X'0D' X'0D' LF X'25' X'0A' For more information about XML document whitespace handling, see "Normalizing whitespace characters".
- The following example shows the effect of the SortCanonical option:
Begin %d is object Xmldoc %d = new %htr is object HttpRequest %htr = new %sl is object Stringlist %sl = new Text To %sl <top p:abc="p" q:xyz="q" xmlns:p="urn:p" xmlns:q="http://q.com" xmlns="urn:default" name="t" id="z15" /> End Text %d:LoadXml(%sl) %htr:AddXml(%d, 'SortCanonical NoEmptyElt') Print %d:Serial(, 'EBCDIC SortCanonical NoEmptyElt') End
The Print statement above (which uses the Serial (XmlDoc/XmlNode function) method of the Janus SOAP XmlDoc API) displays the resulting XmlDoc content added to the HTTPRequest object (formatted with some newlines for the sake of instruction):<top xmlns="urn:default" xmlns:p="urn:p" xmlns:q="http://q.com" id="z15" name="t" q:xyz="q" p:abc="p" > </top>
Comments:
- The reason for the name (SortCanonical) is that this ordering is part of the specification of the Canonical XML Recommendation (http://www.w3.org/TR/xml&hyph.c14n) and the Exclusive Canonical XML Recommendation (http://www.w3.org/TR/xml&hyph.exc&hyph.c14n), which constrain serializations to facilitate processing such as digital signatures.
- Notice the use of the NoEmptyElt option above. This produces an STag (
<top ...>
) and an ETag (</top>
) for an empty element, rather than just the EmptyElemTag (<top ...>
). The canonical XML recommendations state that an STag/ETag pair, rather than an EmptyElemTag, is the serialization for an empty element. - Although SortCanonical uses the Unicode sort sequence, this is limited to Unicode values less than 256 (as of version 6.9 of Janus SOAP, so it is accomplished with an 8-byte EBCDIC to 8-byte Unicode table, which is (for all intents and purposes) merely an EBCDIC-to-ASCII translation.
Usage notes
- The XmlDoc that is passed is serialized into the post data of the request being built. It is not required that you serialize the XmlDoc first.
- Invoking this method erases any post data previously added by AddXML or AddLongString method calls.
- As of Sirius Mods version 6.6, if you do not explicitly set a content-type HTTP request header via AddHeader, AddXml generates a content-type header of &ldquo;text/xml&rdquo; upon a Post. To suppress this automatic header generation, you can set the AutoSendXMLContentType property to False.
- The xmloptions may be specified in any case, for example, you can use
either
NoXmlDecl
ornoxmldecl
, interchangeably. - If one of the line-end
(
CR
,LF
,CRLF
) options or ifIndent
is specified, and an element to be serialized has thexml:space="preserve"
attribute, then within the serialization of that element and its descendants, no line-end (nor indentation) characters are inserted to provide readability. In addition, thexml:space="default"
attribute has no effect under these options: specified by itself, it does not influence serialization, nor does it cause resumption of readability line-ends or indents if they were suspended by a containingxml:space="preserve"
. - As of version 6.7, the AddXml method uses the
character references specified in the XML Canonicalization specification
(http://www.w3.org/TR/xml-c14n) to
display the following characters:
- For Attribute nodes: tab, carriage return, and linefeed
- For Text nodes: carriage return
Since the character references are not subject to the standard XML whitespace normalization (so not removed), a serialized document (or subtree) that is then deserialized will retain this whitespace.
These character references are used:
tab &amp;#x9; CR &amp;#xD; LF &amp;#xA; The EBCDIC and corresponding ASCII encodings of the characters is:
&nbsp; EBCDIC ASCII tab X'05' X'09' CR X'0D' X'0D' LF X'25' X'0A' For more information about XML document whitespace handling, see "Normalizing whitespace characters".
- The following example shows the effect of the SortCanonical option:
Begin %d is object Xmldoc %d = new %htr is object HttpRequest %htr = new %sl is object Stringlist %sl = new Text To %sl <top p:abc="p" q:xyz="q" xmlns:p="urn:p" xmlns:q="http://q.com" xmlns="urn:default" name="t" id="z15" /> End Text %d:LoadXml(%sl) %htr:AddXml(%d, 'SortCanonical NoEmptyElt') Print %d:Serial(, 'EBCDIC SortCanonical NoEmptyElt') End
The Print statement above (which uses the Serial (XmlDoc/XmlNode function) method of the Janus SOAP XmlDoc API) displays the resulting XmlDoc content added to the HTTPRequest object (formatted with some newlines for the sake of instruction):<top xmlns="urn:default" xmlns:p="urn:p" xmlns:q="http://q.com" id="z15" name="t" q:xyz="q" p:abc="p" > </top>
Comments:
- The reason for the name (SortCanonical) is that this ordering is part of the specification of the Canonical XML Recommendation (http://www.w3.org/TR/xml&hyph.c14n) and the Exclusive Canonical XML Recommendation (http://www.w3.org/TR/xml&hyph.exc&hyph.c14n), which constrain serializations to facilitate processing such as digital signatures.
- Notice the use of the NoEmptyElt option above. This produces an STag (
<top ...>
) and an ETag (</top>
) for an empty element, rather than just the EmptyElemTag (<top ...>
). The canonical XML recommendations state that an STag/ETag pair, rather than an EmptyElemTag, is the serialization for an empty element. - Although SortCanonical uses the Unicode sort sequence, this is limited to Unicode values less than 256 (as of version 6.9 of Janus SOAP, so it is accomplished with an 8-byte EBCDIC to 8-byte Unicode table, which is (for all intents and purposes) merely an EBCDIC-to-ASCII translation.