ParseXml (HttpResponse function): Difference between revisions
m (→Syntax terms) |
m (1 revision) |
(No difference)
|
Revision as of 18:22, 6 November 2012
Deserialize response data to XmlDoc (HttpResponse class)
[Requires Janus SOAP]
The ParseXml method helps you access the document/content from HttpRequest Get, Post, and Send operations. ParseXml deserializes returned XML data into the Janus SOAP XmlDoc object you specify.
Syntax
[%number =] httpResponse:ParseXml( doc, [options]) Throws XmlParseError
Syntax terms
%number | A numeric variable. Successful deserialization returns 0; failure returns a non-zero value. |
---|---|
%httpResponse | A reference to an HttpResponse object that was returned by a Get, Post, or Send method of an HttpRequest object. |
doc | A previously instantiated XmlDoc object which must be EMPTY. |
options | Any valid combination of the following (which are the same as the options of the LoadXML method):
|
Usage notes
- ParseXml is equivalent to, but faster than, issuing the Janus SOAP XML text-conversion method LoadXml against the Longstring returned by Content.
- If the content type header indicates HTML, XML, or plain text, ASCII-to-EBCDIC translation is performed. If the Clsock port definition specifies a translation table for ASCII-to-EBCDIC, that table is used instead of the default.
- None of the options may be specified twice.
- The options may be specified in any case. For example, you can use
WspPreserve
andwsppreserve
, interchangeably.
Whitespace handling
- The “Wsp” whitespace-handling options (WspPreserve, WspNewline, and WspToken) and the CrPreserve whitespace option are mutually exclusive; if none of them is specified, WspNewline is in effect. Although the LinefeedNoTrailingTabs option is also concerned with whitespace, it is distinct from, yet compatible with, any of the three “Wsp” options, but it is not compatible with the CrPreserve option.
- Except for CrPreserve, the whitespace-handling options are applied after the XML standard whitespace conversions that Janus SOAP always applies. As described in "Normalizing whitespace characters", the standard specifies that all carriage return/linefeed sequences and carriage return sequences are to be converted to linefeeds when deserializing. Using the CrPreserve option bypasses this rule.
- The whitespace-handling options do no whitespace conversion (beyond the XML standard conversions) on element content that is “protected” by the
xml:space="preserve"
attribute. “Protected” by the xml:space="preserve" attribute means an element E that either:- has the
xml:space
attribute with the valuepreserve
- is contained in an element A with that attribute and value, and there is no element that is a descendent of A and an ancestor of E with the
xml:space
attribute with the valuedefault
Elements that are not protected by the
xml:space="preserve"
attribute have whitespace handled according to the option in effect for the deserialization. - has the
- Using WspNewline or WspToken reduces the space consumed by individual Text nodes, and in some cases collapses all whitespace content between markup to the null string, so it is not stored as a Text node. This reduces the storage required by the XmlDoc, speeds up XPath and node access processing, and makes the output of the Print subroutine easier to read.
- The LinefeedNoTrailingTabs option only affects Text nodes that contain an initial line-end character followed by any number of tabs and nothing else. The LinefeedNoTrailingTabs effect on such a Text node, whether it is specified with or without any of the “Wsp” options, is to store the value of the node as a single line-end character.
One example of the use of the LinefeedNoTrailingTabs option is an input XML document to be deserialized for which both of the following are true:
- A digital signature is needed of a subtree in the document.
- The input subtree contains a linefeed and one or more tabs that separate markup, and the linefeed must be kept but the tabs discarded for the signature.
For information about exclusive canonicalization, serialization expressly designed for digital signatures, see "Canonicalization".
Deserializing Unicode strings
The ParseXml AllowUntranslatable option lets you deserialize Unicode strings that contain characters that are not translatable to EBCDIC. Otherwise, such characters in an input XML document are detected, an XmlParseError exception with reason UntranslatableUnicode
is thrown, and the request is canceled.
This default detection of non-translatable characters may suit your purposes. That is, it ensures that subsequent access to the deserialized content is performed without any Unicode to EBCDIC translation errors. For example:
%doc:ParseXml ... %val Longstring %val = %doc:Value(%xpath)
The assignment to the EBCDIC string %val
will not fail due to a Unicode translation problem: if there is any untranslatable Unicode (including, of course, strings in the XML document which your application never accesses), the ParseXml operation fails.
If you use AllowUntranslatable, all Unicode characters in a serialized input XML document are allowed and stored in the XmlDoc. Your stored data may contain content that is not translatable to EBCDIC, however. A subsequent attempt to access such content that performs Unicode to EBCDIC translation might cause request cancellation. You should therefore use AllowUntranslatable only if there is also a check for translatability when parts of the XmlDoc that may have non-translatable Unicode content are accessed.
The code below shows a way to get the benefit of specifying AllowUntranslatable while limiting the risk of request cancellation. In the example, it is believed that only the element comments
might contain untranslatable Unicode among all the data accessed from the XML document:
%resp:ParseXml(%doc, 'AllowUntranslatable') ... %uVal Unicode %val Longstring %uVal = %node:Value('comments') Try %val = %uVal:UnicodeToEbcdic Catch CharacterTranslationException %val = %uVal:UnicodeToEbcdic(CharacterEncode=True) Print 'Untranslatable Unicode, character encoded:' - And %val End Try
Note: Unicode values, untranslatable or not, are always allowed when they are added to an XmlDoc using one of the Janus SOAP XML Add or Insert methods which “directly store” into an XmlDoc. For example, the following fragment adds an Element node with a value that is the Unicode trademark sign:
%node:AddElement('notation', '™':U)
Unicode input characters
The ReplaceUnicode option lets you replace certain Unicode input characters with those characters you have explicitly specified (by UNICODE commands in your site's Model 204 CCAIN stream).
For example, assume the following command is in CCAIN:
UNICODE Table Standard Rep U=2122 '(tm)'
Given the above command, the ReplaceUnicode option for LoadXml is shown in the following fragment:
%u Unicode Initial('<a>') %u = %u:UnicodeWith('2122':X:Utf16ToUnicode) %u = %u:UnicodeWith('</a>':U) %d:LoadXml(%u, 'ReplaceUnicode') %d:Print
The result is:
<a>(tm)</a>
In the preceeding example, the stream of input characters to LoadXml contains the Unicode character U+2122. Since the ReplaceUnicode option applies to both the stream of input characters and to the character value of character references, consider the following fragment (assuming the same CCAIN line as above):
%d:LoadXml('<a>™</a>', 'ReplaceUnicode')
The result is also:
<a>(tm)</a>
In this case, U+2122 does not occur in the input character stream, but it is the value of the character reference.
Notes:
- It is an error to be processing a replacement string within a character reference. For example, assume the following two lines are in CCAIN:
* Replace superscript 2 with digit '2': UNICODE Table Standard Rep U=00B2 '2'
Given the above command, the following fragment gets a parse error, because the replacement string is being used as part of a character reference:
%d:LoadXml('<a>&#x' With '²':U With ';</a>', - 'ReplaceUnicode')
As a consequence of this rule, a replacement string should not contain an ampersand character (assuming that the ReplaceUnicode option will be used).
- Replacement of a Unicode character due to the ReplaceUnicode option is only done while processing names and values in the XML document. It is an error if the end of the name or value occurs and the replacement string has not been exhausted. In other words (again assuming that the ReplaceUnicode option will be used), a replacement string should not have “XML markup” that might end a string, such as a quotation mark or a left angle bracket (
<
). For example, assume the following line is in CCAIN:UNICODE Table Standard Rep U=2122 '(trademark)<tm>'
Given the above command, the following fragment gets a parsing error, because the '<' that is encountered in the replacement string ends the element content:
%d:LoadXml('<a>™</a>':U, 'ReplaceUnicode')
- If a parsing error occurs after processing a Unicode character that has been replaced, the error display of the input stream will contain the replacement string, and the replaced character will not be displayed. However, if the character being replaced was introduced as a character reference, the character reference remains in the display of the input stream.
Example
In the following example, ParseXml deserializes into %doc
the XML data (stored in %httpresp
) returned from a Post call:
%httpreq is object httpRequest %httpreq = new ... %httpresp = %httpreq:post('HTTPCLI') %doc is object xmlDoc %doc = new %httpresp:parseXml(%doc, 'ErrRet') %doc:print ...
See also
- Working with Janus SOAP XmlDoc objects is described in detail in "XML processing in Janus SOAP".