Problem:

While most specifications that use XML do not require special encoding of data, XML Extensions and Business Information Server may be used in situations where APIs and specifications have not anticipated the use of XML as an intermediate data representation. In these cases, binary data outside the range of characters that may be easily transmitted by an XML code set may be specified.

Resolution:

W3C has several specifications that may be used when binary data is to be transmitted within a transport protocol that does not allow all possible character code points (such as ASCII control characters, binary zero, etc.). One of the most widely used is base64.

XML Extensions converts data described as numeric within the COBOL program to XML standard character strings that represent the value of the number. However, when binary data must be embedded in an alphanumeric item, an encoding scheme must be used by the COBOL program to convert the character string into another character string which contains only characters that can be transmitted through XML.

The attached file provides RM/COBOL subroutines that allow conversion to and from base64 encoding. The base64 scheme uses an alphabet of 64 character, including the upper- and lower-case western alphabet, the ten digits, and the plus ( ) and slash (/) characters. Four base64 characters (octets) are used to represent every three characters (octets) in the unencoded string. Special handling is prescribed for strings that are not an even multiple of three octets. See section 6.8 in the referenced article (link at right) for additional details.

The attached file also contains a special subroutine that calculates a message digest for the input string and produces a base64 representation of the message digest, rather than input string itself. This can be useful when a message digest is required to assure that a message (the input string) has not been changed; the receiver of the message can calculate a message digest and compare to the sender's message digest. Message digests are also useful in optimistic concurrency record locking schemes to detect changes in a record before updates or deletes are committed.

Problem:

While most specifications that use XML do not require special encoding of data, XML Extensions and Business Information Server may be used in situations where APIs and specifications have not anticipated the use of XML as an intermediate data representation. In these cases, binary data outside the range of characters that may be easily transmitted by an XML code set may be specified.

Resolution:

W3C has several specifications that may be used when binary data is to be transmitted within a transport protocol that does not allow all possible character code points (such as ASCII control characters, binary zero, etc.). One of the most widely used is base64.

XML Extensions converts data described as numeric within the COBOL program to XML standard character strings that represent the value of the number. However, when binary data must be embedded in an alphanumeric item, an encoding scheme must be used by the COBOL program to convert the character string into another character string which contains only characters that can be transmitted through XML.

The attached file provides RM/COBOL subroutines that allow conversion to and from base64 encoding. The base64 scheme uses an alphabet of 64 character, including the upper- and lower-case western alphabet, the ten digits, and the plus ( ) and slash (/) characters. Four base64 characters (octets) are used to represent every three characters (octets) in the unencoded string. Special handling is prescribed for strings that are not an even multiple of three octets. See section 6.8 in the referenced article (link at right) for additional details.

The attached file also contains a special subroutine that calculates a message digest for the input string and produces a base64 representation of the message digest, rather than input string itself. This can be useful when a message digest is required to assure that a message (the input string) has not been changed; the receiver of the message can calculate a message digest and compare to the sender's message digest. Message digests are also useful in optimistic concurrency record locking schemes to detect changes in a record before updates or deletes are committed.

Problem:

While most specifications that use XML do not require special encoding of data, XML Extensions and Business Information Server may be used in situations where APIs and specifications have not anticipated the use of XML as an intermediate data representation. In these cases, binary data outside the range of characters that may be easily transmitted by an XML code set may be specified.

Resolution:

W3C has several specifications that may be used when binary data is to be transmitted within a transport protocol that does not allow all possible character code points (such as ASCII control characters, binary zero, etc.). One of the most widely used is base64.

XML Extensions converts data described as numeric within the COBOL program to XML standard character strings that represent the value of the number. However, when binary data must be embedded in an alphanumeric item, an encoding scheme must be used by the COBOL program to convert the character string into another character string which contains only characters that can be transmitted through XML.

The attached file provides RM/COBOL subroutines that allow conversion to and from base64 encoding. The base64 scheme uses an alphabet of 64 character, including the upper- and lower-case western alphabet, the ten digits, and the plus ( ) and slash (/) characters. Four base64 characters (octets) are used to represent every three characters (octets) in the unencoded string. Special handling is prescribed for strings that are not an even multiple of three octets. See section 6.8 in the referenced article (link at right) for additional details.

The attached file also contains a special subroutine that calculates a message digest for the input string and produces a base64 representation of the message digest, rather than input string itself. This can be useful when a message digest is required to assure that a message (the input string) has not been changed; the receiver of the message can calculate a message digest and compare to the sender's message digest. Message digests are also useful in optimistic concurrency record locking schemes to detect changes in a record before updates or deletes are committed.

Problem:

While most specifications that use XML do not require special encoding of data, XML Extensions and Business Information Server may be used in situations where APIs and specifications have not anticipated the use of XML as an intermediate data representation. In these cases, binary data outside the range of characters that may be easily transmitted by an XML code set may be specified.

Resolution:

W3C has several specifications that may be used when binary data is to be transmitted within a transport protocol that does not allow all possible character code points (such as ASCII control characters, binary zero, etc.). One of the most widely used is base64.

XML Extensions converts data described as numeric within the COBOL program to XML standard character strings that represent the value of the number. However, when binary data must be embedded in an alphanumeric item, an encoding scheme must be used by the COBOL program to convert the character string into another character string which contains only characters that can be transmitted through XML.

The attached file provides RM/COBOL subroutines that allow conversion to and from base64 encoding. The base64 scheme uses an alphabet of 64 character, including the upper- and lower-case western alphabet, the ten digits, and the plus ( ) and slash (/) characters. Four base64 characters (octets) are used to represent every three characters (octets) in the unencoded string. Special handling is prescribed for strings that are not an even multiple of three octets. See section 6.8 in the referenced article (link at right) for additional details.

The attached file also contains a special subroutine that calculates a message digest for the input string and produces a base64 representation of the message digest, rather than input string itself. This can be useful when a message digest is required to assure that a message (the input string) has not been changed; the receiver of the message can calculate a message digest and compare to the sender's message digest. Message digests are also useful in optimistic concurrency record locking schemes to detect changes in a record before updates or deletes are committed.