Progress^® DataDirect XML Converters^® for Java^™ Release 6.2
README
November 2020

Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.

This README file contains additional information not included in the Progress^® DataDirect XML Converters^® for Java^™ documentation.

Contents

This readme contains the following sections:

• Release 6.2 Features

• Change History
  1893be, 1893bd, 1893bc, 1893bb, 1893ba, 1893az, 1893ay, 1893ax, 1893aw, 1893av, 1893au, 1893at, 1893as, 1893ar, 1893aq, 1893ap, 1893ao, 1893an, 1893am, 1893ak, 1893aj, 1893ai, 1893ah, 1893ag, 1893af, 1893ae, 1893ad, 1893ac, 1893ab, 1893aa, 1893z, 1893y, 1893x, 1893w, 1893v, 1893u, 1893t, 1893s, 1893r, 1893q, 1893p, 1893n, 1893m, 1893k, 1893j, 1893i, 1893h, 1893g

• Installation

• Using the Online Documents

• DataDirect XML Converters Files

• Third-Party Licensing Agreements

Release 6.2 Features

DataDirect XML Converters 6.2 includes the following new features:

• Multiline support for CSV and TAB Converters — Both the CSV (Comma Separated Values) and TAB converters now support the “multiline= URI” property, which determines whether a quoted string can contain a newline. If “multiline=no” (the default), a newline anywhere in a quoted string terminates the row. If “multiline=yes”, a newline inside a quoted string is considered part of the content of that field.
• JSON strips BOM from InputStream or Reader — If an InputStream or Reader starts with a Byte Order Mark (BOM), the JSON converter automatically strips it. This is useful when a file containing a BOM is read into a String or byte[] and passed through using a StringReader or ByteArrayInputStream.
• JSON supports top-level arrays — Although the specification at http://json.org specifies that a JSON string must start and end with braces ({}), sometimes it is convenient to process a simple array. If the JSON converter encounters a bare array as the outermost construct, it will imply a set of braces surrounding it to return a top-level object.
• Support for new EDI versions — XML Converters for Java provides support for the following versions of currently supported Electronic Data Interchange (EDI) dialects:
• AL3 — ACORD AL3 Added up through 06/2012
• EDIFACT — Versions D10A, D10B, D11A, D11B, D12A, D12B, D13A and D13B
• HIPAA — Updated 005010A1 and 005010A2
• IATA PADIS — Versions 11-1 and 12-1
• X12 — Versions 006030 and 006040
• Current XML Converters for Java support — XML Converters for Java supports the following EDI dialects and message formats:
• ACORD AL3: All group versions from 11/1989 to 06/2012
• EANCOM: 1997, 2001, 2002
• EDIFACT: 88-1, 90-1, 90-2, 91-1, 91-2, 92-1, 93-2, S93A, D93A, D94A, D94B, D95A, D95B, D96A, D96B, D97A, D97B, D98A, D98B, D99A, D99B, D00A, D00B, D01A, D01B, D01C, D02A, D02B, D03A, D03B, D04A, D04B, D05A, D05B, D06A, D06B, D07A, D07B, D08A, D08B, D09A, D09B, D10A, D10B, D11A, D11B, D12A, D12B, D13A, D13B, D14A, D14B, D15A, D15B, D16A, D16B, D17A, D17B, D18A, D18B, D19A, D19B
• Edig@s: 2.2, 3.0, 3.1, 3.2, 4.0
• HIPAA: 004010A1, 005010, 005010A1, 005010A2
• HL7: 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6
• IATA AHM 780: 2010
• IATA Cargo-IMP: All message types in versions 21 through 28
• IATA PADIS: 92-1, 93-1, 93-2, 94-1, 94-2, 95-1, 95-2, 96-1, 96-2, 97-1, 97-2, 98-1, 98-2, 99-1, 99-2, 00-1, 00-2, 01-1, 01-2, 02-1, 02-2, 03-1, 03-2, 04-1, 04-2, 05-1, 06-1, 07-1, 08-1, 11-1, 12-1
• NCPDP SCRIPT: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 2.0, 3.0, 3.1, 4.0, 4.1, 4.2, 4.3, 4.4, 5.0, 6.0, 7.0, 7.1, 8.0, 8.1, 9.0, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9
• NCPDP Telecommunication: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 6.0, 7.0, 7.1, 8.0, 8.1, 8.2, 8.3, 9.0, A.0, A.1, B.0, C.0, C.1, C.2, C.3, C.4, D.0, D.1, D.2
• TRADACOMS: 93.1, including Book Industry Communications (BIC) extensions
• X12: 003030, 003040, 003050, 003060, 003070, 004010, 004020, 004030, 004040, 004041, 004042, 004050, 004051, 004052, 004060, 005010, 005020, 005030, 005040, 005050, 006010, 006020, 006030, 006040, 006050, 007010, 007020, 007030, 007040
• Enhanced support for X12 BDS Segments — The following binary enclosures are supported in several formats, with Baudot being added for 6.2:
• ASB (Baudot)
• B64 (Base 64)
• HDC (Hexadecimal Filter)
• R64 (Radix 64; also referred to as “ASCII Armor”)
• UUE (UUencoding)
• NOF (No Filter)
• ZZZ (Mutually Defined; passed through as NOF)

If you want to stop the conversion if the input is not in a specific format instead of forcing the incoming message to act like a specific format, refer to the topic “Stopping a Conversion If the Input Does Not Match What is Expected” in the DataDirect XML Converters for Java User’s Guide and Reference.

• EDIFACT without UNB (or UIB for interactive messages) — Formerly, an Electronic Data Interchange For Administration, Commerce, and Transport (EDIFACT) input source would require a UNB segment. Starting with version 6.2, if the file starts with UNH (or UIH), a UNB (or UIB) segment “materializes” without generating a warning and is populated with default values. If the “syntax=” or “chr=” URI properties are used, these settings are prioritized in the created segment. This also applies to EDIFACT-derived dialects, such as Edig@s, IATA/PADIS, EANCOM, and NCPDP/SCRIPT.
• TRADACOMS calculation corrected for EXLV — The converter for TRADACOMS calculated the EXLV element value incorrectly, which always yielded a zero (0). This has been corrected.
• New GENERIC dialect — There is a new GENERIC dialect for custom flat file work. It is primarily available for use by Progress Professional Services, but can also be configured by the manual creation of SEF files.
• Updated and added URI properties — The following are the URI properties that have been updated or newly added:
• Auto-detect override now applies to “message=” URI property — The “dialect=” and “version=” URI properties that were added in version 6.0 let you override the XML Converters auto-detect feature when converting EDI to XML. With version 6.2, the message can also be specified. NOTE: This forces the message to be processed as if it were the message specified in the EDI file.
  • “dialect=”: lets you specify an EDI dialect, overriding the auto-detection of the dialect specified in the EDI file.
  • “version=”: lets you specify an EDI version, overriding the auto-detection of the version specified in the EDI file.
  • “message=”: lets you specify an EDI message, overriding the auto-detection of the message specified in the EDI file.
• New “terminate=” URI property to stop reading input — This property stops reading the input at the specified character. If the input stream contains a character value that matches the value of this property, the input streaming stops at that character. This is a way to define the end-of-file marker so that no data after this point will be read. It applies only when reading EDI and does not apply when parsing an XML file.
• New “toobig=” URI property for large segments — This property allows proper tuning of large segments. For some dialects, such as HL7, it is common to have large segments that can contain more than 100 elements. Normally, the error recovery algorithm applies for large segments and assumes that separators are specified improperly or that the input is damaged.
• New “syntax=” URI property for forcing the syntax level of EDIFACT-style input — This property allows the syntax to be overridden from the assumed value in the UNB0101/0001 element. It is especially useful when the input stream does not contain a UNB or UIB segment and one must be created.
• Support for BOM while writing EDI to the Writer class with UTF-8 or UTF-16 using the new “bom=” URI property — This property allows you to insert a BOM while writing EDI to the Writer class. The Java Writer classes do not start the output by writing a Byte Order Mark (BOM). Therefore, this property is used to insert a BOM at the start of the file. Use “bom=yes” to insert the BOM, or “bom=no” (the default) to begin writing without inserting a BOM.
• Formatted dates option in XML output using the new “iso=” URI property — This property formats date and time in the XML output. Formerly in the XML output, date and time would be in the same format as in the input file. Now with “iso=yes”, date and time can be formatted according to the ISO 8601 date and time formats.
• New “numpad=” URI property to pad numbers with alternate characters — This property allows padding numbers with alternate characters. Typically, the converter pads numbers that go in fixed-width fields with spaces or zeros. This property allows padding numbers with alternate characters if it is syntactically valid to choose an alternative amongst ACORD/AL3, EDIFACT-style messages, or flat files. Also, in a flat file conversion using the GENERIC converter, numbers can get padded with NUL characters (0x00). In this case, we recommend that you specify “numpad=NUL”.
• New “delimiter=” URI property — This property specifies that delimiters be used for quoted strings in flat files. By default, “delimiter=Q” means either single or double quotes can be used as delimiters for quoted strings. To specify a specific character, specify the Unicode value. For example, “delimiter=0x22” for double quotes and “delimiter=0x27” for single quotes.
• New “default” value for “setup=” URI property — “setup=default” is now a valid choice for the setup= settings. Instead of turning the emitting of a setup segment on or off explicitly, you can defer to the default value for the specific dialect. For example, for EDIFACT the default is ‘from XML’; for other dialects, it may generate the header segment in both directions.
• New “ta1=” URI property allows inclusion of the TA1 segment in a 999 reply — The following settings can be used for the “ta1=” URI property:
  • “ta1=no”: does not generate the TA1 segment in reply. This is the default value.
  • “ta1=yes”: always generates the TA1 segment in reply.
  • “ta1=auto”: uses the ISA14 setting from the incoming interchange to determine whether to add the TA1 segment in reply.
• X12/HIPAA response message 999 selection using the “xr=” URI property — This property allows you to set the type of transaction message to be generated. Instead of using the default 997 response message, the “xr=” property can be set to 999. Before you set this property to 999, make sure that the version of X12 that is being used has the 999 response message, which was introduced in 005010. This property is HIPAA-aware. Therefore, for version 0050x0, it writes the 005010 X231 version of 999, and for 0060x0, it writes the 006010X290 version.

Change History

• Build 1893be
  • Fixed problem with repeated complex elements in SHP, CNE, and NFY segments in CargoIMP messages FWB/16, FWB/17, FHL/4, and FHL/5.
• Build 1893bd
  • Added support for the CargoIMP FWB/16 and FWB/17 messages.
  • Added support for the CargoIMP FHL/4 and FHL/5 messages.
• Build 1893bc
  • Added EDIFACT D19B.
  • A component separator in incoming XML content was not triggering a DDEE0010 exception.
    In the rare case that the separator character should still be emitted as content into the EDI (which violates the standard but sometimes is useful if the element is the last element in the segment), the ignore=10 connection property can be used to suppress the error and process the character as a regular content character.
• Build 1893bb
  • Certified for Java version 6 through 11.
• Build 1893ba
  • New EDIFACT versions: D17A, D17B, D18A, D18B and D19A.
• Build 1893az
  • For IATA/PADIS, often the EDIFACT "repeat" character is not used when the repeating element is a complex element and is the last element in the segment. Instead of using the "repeat" character, the "element" character is used. For example:
    

    In this particular segment in IATA PNRGOV 11-1 segment RCI, there is only one element, which is composite element C330, and which repeats up to 9 times.
    Normally in this case the repeat character, in this case "*", would be used to separate the two instances, per the EDIFACT standard.

    RCI+UA:ABCDEF:1:020219:1000*1V:ZYXWVU:1'

    However, the typical usage instead uses the element character:

    RCI+UA:ABCDEF:1:020219:1000+1V:ZYXWVU:1'

    This change alters the parser so that if the last element is a complex, repeating element, we automatically assume that the element separator should be treated as the repeat separator, and parse the segment properly.

• Build 1893ay
  • In X12 or HIPAA, when a simple element contains a string that uses a character that is normally reserved as a separator, error DDEE0010 "Composite element seen where simple element expected." is generated.
    This causes problems when a text element contains this character, because while according to strict rules this is an error, we know that in this particular case it should be treated as just a plain text character.
    For example, in the following segment, when ISA16 (I15: Component Element Separator) is ":", normally an error DDEE0010 would be emitted, since the URL element contains a colon:
    

    PER*IC**URL*http://www.progress.com~

    Even though PER04 is a string (AN) type and not a complex type, the parser sees the separator and wants to break it into pieces.
    A change in this patch allows the using ignore=10 to ignore the syntax error, and in this particular case, if the element is a simple type, the component separator will be treated like any other character.
  • A similar problem can happen when a simple element that is not marked as "repeating" has text containing the repeat character from ISA11 (I65: Repetition Separator). In this case, using ignore=1 will ignore the syntax error, and provide the fallback behavior of generating output as if the repetition character were just an ordinary character.
    For example, assuming a PER segment looked like this, and the repeat character was defined as a colon:
    

    PER*IC**URL*http://www.progress.com~

    Normally, an error DDEE0001 would be emitted, because PER04 is not marked as an element that repeats. The old behavior with ignore=1 would have generated this for output for the PER04 element:
    

    <PER04>http</PER04>
    <PER04>//www.progress.com</PER04>

    Note that since the parser detected the repeat character, the field would repeat.
    The new behavior with ignore=1 is different, since the definition for PER04 says it isn't supposed to repeat, so we have an improved compensating behavior:

    <PER04>http://www.progress.com</PER04>

• Build 1893ax
  • Fixed typograpical error that could cause NPE when using IATA/PADIS 13-1.
• Build 1893aw
  • Added support for CargoIMP FSA/13, FSA/14, FSU/13 and FSU/14, from the 29th-34th edition of the IATA CIMP manual.
• Build 1893av
  • Added supplemental messages for IATA/PADIS
    • ACKRES - 12-1 and 13-1
    • GOVREQ - 12-1 and 13-1
    • PNRGOV - 12-1 and 13-1
  • Reduced the memory requirements for JSON adapter.
  • The JSON standard allows a wide variety of characters in key names, much larger than XML allows in element names. There are times when it would be convenient to use this wider repertoire. This patch introduces the JSON "name=" URI property. This is the name of an attribute in the XML that will hold the actual name of the JSON key. For example, with name=JSONNAME:root=contents set, the following XML converts to the following JSON, and vice-versa:
    

    XML

    JSON

    <contents>     <a JSONNAME="*beta*">etaonrishdlfcmugypwbvkxjqz</a>     <b JSONNAME="@company@">XYZZY</b>     <c JSONNAME="$from$">2017-08-28</c>     <d JSONNAME="%to%">2018-01-18</d>     <e JSONNAME="|dates|">         <f JSONNAME="2018-01-18">             <assets>89.8</assets>             <liabilities>90.67</liabilities>             <capital>89.66</capital>             <income>90.49</income>             <expenses>98.51</expenses>         </f>     </e> <contents>

    {     "*beta*": "etaonrishdlfcmugypwbvkxjqz",     "@company@": "XYZZY",     "$from$": "2017-08-28",     "%to%": "2018-01-18",     "|dates|": {         "2018-01-18": {             "assets": 89.8,             "liabilities": 90.67,             "capital": 89.66,             "income": 90.49,             "expenses": 98.51         }     } }

• Build 1893au
  • Starting with build 1893as, in the JSON converter, in some contexts the string= and array= URI properties might inadvertently match empty elements. This has been fixed.
• Build 1893at
  • Starting with build 1893as, in the JSON converter, in some contexts the string= and array= URI properties might inadvertently match the child of the desired element instead of the element itself. This has been fixed.
• Build 1893as
  • In the JSON converter, both the string= and array= URI properties have updated syntax support:
    • A comma-separated list of terms may be used; if the element name matches any of them the operation will be taken.
    • The syntax prefix:* may be used to signify all elements for a given namespace prefix.
    • The syntax *:name may be used to signify the elements named name no matter which namespace they are in, as long as they have a namespace prefix.
    • The syntax * will match any element name. This is especially useful when path expressions are used (see next point).
    • A slash-separated path may be used. For example abc/def means that only the def elements immediately under abc elements will be considered. Multiple levels may be used, and a * can be used in the middle of the path.
    • In addition, a regular expression may be used for each component of the path name.
• Build 1893ar
  • In the JSON converter, added a new string= URI property, to force specific elements to always emit their content as a quoted string and not try to interpret it as a numeric, boolean or null value. It accepts the same values as the array= option added in the 1893aq patch.
• Build 1893aq
  • In the JSON converter, made clearer the cases when input XML that looked numeric would render as a string or as a number in JSON. Generally, if the number starts with a "0", it will be emitted as a quoted string, so that zip codes and dates will keep their format. Numbers will be converted to their canonical format, so that for example 20, 20.0 and 20.000 will all come out as 20. This is in the letter and spirit of the standard at json.org.
  • A new URI option array= has been added to the JSON converter. Without the use of this option, elements that have a single instance are emitted as JSON objects, while those that repeat are emitted as JSON arrays. Using this option allows named elements to always be emitted as arrays, even if they have only once instance. The syntax is array=elements, where elements is a list of the names to be always treated as arrays, separated by vertical bar characters ("|"). A regular expression may also be used. The list is case-sensitive, and should not include any extra spaces. For example, to force element "quote" to always be treated as an array, use array=quote. To force all elements under the namespace prefix "px" to be treated as an array, use array=px.*. To force elements "apple" and "orange", use array=apple|orange. Finally, array=* will cause all elements to be treated as arrays.
• Build 1893ap
  • Added support for DM 042316 which changes the set of allowed characters within an X12 ID element.
• Build 1893ao
  • Added support for X12 007040.
    • X12 supports release= URI option for version 007040 and higher
    • The release character and character encoding may be set in the ISX segment.
    • The ISX segment is generated in the analyze output if a ISX segment is used or if the release character is specified as a URI property.
  • Fixed ID data type validation to allow space characters in ID values.
  • In the HIPAA 005010 275 message, a missing BGN01 value will no longer cause a NullPointerException.
  • Fixed a bug in generating a HIPAA 997 response during analysis that could cause a condition where we were showing all errors or no errors if a "Not Used" element was seen, instead of just those appropriate to the 997.
• Build 1893an
  • The following HIPAA standards are currently marked with Required/Situational/Not Used attributes. Bold means new to this patch.
    • 005010 X210 275
    • 005010 X213 277
    • 005010 X214 277
    • 005010 X218 820
    • 005010 X221 850
    • 005010 X221A1 850
    • 005010 X228 277
    • 005010 X230 997
    • 005010 X231 999
    • 005010 X231A1 999
• Build 1893am
  • When a "Not Used" element contains a value, the error code was wrongly behaving as if the value was not in the codelist. This fix means also that the 997 response will correctly not include "Not Used" errors, as they are the sole province of the 999.
  • In the analysis report, a CTX segment should only be used when "situational trigger" conditions occur.
  • Also in the analysis report, we now only fill in the repetition value (used in AK40103, CTX0503 and IK40103 elements) when the element is in fact a repeating element. Otherwise, the value is omitted.
  • The following new standards are supported:
    • HIPAA 005010 X213 277
• Build 1893ak
  • Added validation on contents of ST03 for HIPAA 005010 transaction sets that require it.
  • The following new standards are supported:
    • HIPAA 005010 X214 277
    • HIPAA 005010 X228 277
  • The following HIPAA standards are currently marked with Required/Situational/Not Used attributes. Bold means new to this patch.
    • 005010 X210 275
    • 005010 X214 277
    • 005010 X228 277
    • 005010 X230 997
    • 005010 X231 999
    • 005010 X231A1 999
• Build 1893aj
  • In X12 (and HIPAA), there is no character 'release' or 'escape' mechanism. This means if a character that is already used as a separator is found within the value in incoming XML, the X12 conversion would fail with a fatal error. This patch introduces a change to the invalid= option. For X12 converting from XML, if the invalid= option is set, any characters that match the element, component, segment or repeat characters will be replaced with the character assigned. To simply drop the invalid character, use invalid=DROP.
  • For X12 and EDIFACT, in some cases when svd=yes is set, an "hours" value of "00" would cause an error when it should have been accepted.
  • Instead of having to choose between generating 997 and 999 messages during an analysis pass, you can now use xr=997+999 as a choice to generate a single output report containing both.
  • The HIPAA 005010 X210 275 message properly validates the two separate cases, when BGN01 is 02 and when it is 11, as far as the PER and STC segments are concerned.
  • Starting with this patch, all HIPAA standards will be marked with the Required/Situational/Not Used attributes. So far, the following messages have been updated:
    • 005010 X210 275
  • The HTML output has been enhanced to show syntax constraints (as used by X12 and EDIFACT-style syntaxes) when the intra=yes URI property is used.
  • The HTML output has also been enhanced to show Required/Situational/Not Used flags where relevant.
• Build 1893ai
  • A new option, svd=yes|no (Cross-Element Date Validation, default no) enables the ability to validate variable-format dates in EDIFACT and related dialects (including IATA/PADIS and EANCOM), and X12 and related dialects (including HIPAA).
    In EDIFACT dialects, there is an element 2379 (Date or time or period format code) used in many segments which sets the format for the preceding 2380 (Date or time or period text) element.
    In X12 dialects, there is an element 1250 (Date Time Period Format Qualifier) used in many segments which sets the format for the following one or more 1251 (Date Time Period) elements.
    Before this patch level, the converter ignored the validation format, and only checked the format of date elements that were explicitly the DT X12 data type, and never for EDIFACT (since it has no date type). With this patch forward and with this URI option enabled, the converter validates using these formats.
• Build 1893ah
  • In some cases, a X12 or HIPAA BIN segment with an incorrect length could cause a NullPointerException while executing the analysis report.
  • The analysis report is now more robust in estimating position within the EDI file organization when recovering from missing mandatory segment errors.
• Build 1893ag
  • In an X12 or HIPAA BIN segment, if it is detected that the declared length of the data in BIN01 does not match the actual length of the data in BIN02, a specific error code is used.
    Note that because the content is unescaped, it is possible that an incorrect length can still lead to misleading messages. For example, the length could be such that the entire next segment would be wrongly included as part of the value, in which case an exception about a segment missing or being out of place would be thrown. This is because a wrong length can lead to ambiguous error conditions.
    In order to help debug these problems, when the exception is thrown, the declare length and an estimated actual length are both included in the exception text.
  • License extensions will now work past the end of the year 2017.
• Build 1893af
  • Fixes default encoding for EDI which should be blank and not "utf-8", to let the native adapter set the default, and to allow Stylus Studio to correctly detect that the default is changed to UTF-8.
• Build 1893ae
  • Adds support for EDIFACT D14A, D14B, D15A, D15B, D16A and D16B.
  • Skip CR or LF characters in NCPDP/Telecommunications files
  • Properly detect errors when sniffing malformed NCPDP/Telecommunications files
• Build 1893ad
  • Adds support for X12 006050, 007010, 007020, and 007030.
  • GENERIC ALPHA data type was not truncating insignificant blank spaces in all cases.
• Build 1893ac
  • Fixes the problem involving altering the minimum or maximum length of an element inside of a composite element. If there is a composite element that is specified in the SEF file, and the minimum or maximum length of one of the elements in that composite is overridden, but the element itself is not included in the SEF file, the adjusted length was ignored.
• Build 1893ab
  • Added new llnx=<integer> URI parameter. By default, the X12 and HIPAA analysis reports generate loop names with a maximum length of four characters, as per the standard for the AK3 segment. However, some HIPAA messages use longer loop names, so this parameter allows the user to adjust the length to a different number. For example, for HIPAA typically a value of llnx=6 would be used.
• Build 1893aa
  • Fixed NullPointerException in GENERIC segment when source value comes from a point past the physical length of the row.
• Build 1893z
  • Fixed some cases where X12 and HIPAA elements had their repeat count set to 1 instead of the actual value. This affected some of the following elements in each version from 004030 forward:
    CAS02, COB04, COM03, CQ07, CTX01, DMG05, DRA01, DRA03, DRA11, DRA13, DRA15, EB03, EB13, EB14, EMS15, ENM04, EQ01, EQ02, EQ05, HCR03, HLH01, ISI02, ISI04, RAS03, SCT09, SV107, SV311, SV605, SV707, WLD04, and WLD07
  • HIPAA transaction set updates:
    • Added:
      • 005010 X210 275
    • Added non-amended versions:
      • 004010 X092 270
      • 004010 X092 271
      • 004010 X093 276
      • 004010 X093 277
      • 004010 X094 278
      • 004010 X061 820
      • 004010 X095 834
      • 004010 X091 835
      • 004010 X097 837D
      • 004010 X096 837I
      • 004010 X098 837P
    • Updated amendments:
      • 005010 X222 837P (A2)
      • 005010 X223 837I (A3)
      • 005010 X224 837D (A3)
    • Support current errata for:
      • 005010 X279 270 and 271 (E1 and E2)
      • 005010 X212 276 and 277 (E1, E2 and E3)
      • 005010 X216 278 (E1 and E2)
      • 005010 X217 278 (E1, E2 and E3)
      • 005010 X218 820 (E1 and E2)
      • 005010 X220 834 (E1 and E2)
      • 005010 X221 835 (E1 and E2)
      • 005010 X222 837P (E1)
      • 005010 X223 837I (E1)
      • 005010 X224 837D (E1)
      • 005010 X210 275 (E1)
• Build 1893y
  • Support root= URI parameter on JSON converter. root=<name> allows the root element name to be set.
  • Support attr= URI parameter on JSON converter. attr=<string> prepends the <string> to each attribute that is converted to JSON, so that attributes are recognizable as such. For example, attr=@ means that each attribute name in JSON would look like {"@name":value} instead of {"name":value}.
  • A new URI parameter, length=min|max|both|none, is supported when generating XML Schemas for EDI definitions. The default is length=max. When length=none is set, neither minLength nor maxLength attributes are generated in the schema. When length=min is set, minLength attributes generated. When length=max is set, which is the default, maxLength attributes are generated. When length=both is set, both are generated. Note that in some cases, even with the setting turned on, sometimes a minLength/maxLength will not be written. This is because the rules for XML Schema length checking do not always match the rules that EDI uses, so in some cases there is no reliable way to test length.
• Build 1893x
  • The new EDIFACT encoding "KECA" is supported.
  • Fix ClassCastException in API Stylus Studio uses to detect version and dialect when a known dialect but unknown version is detected.
• Build 1893w
  • When using strict=yes, the ST02 field in X12 and HIPAA containing text other than digits will no longer fail validation with a DDEE0206 error.
• Build 1893v
  • com.ddtek.xmlconverter.meta.DataType.getFacets() no longer includes DataTypeFacet.FORMAT in the list of type facets, because it is handled specially in the SEF file .FORMAT line and not as a format= property.
  • com.ddtek.xmlconverter.meta.Dialect has a new method String[] getSegmentParseModes(). This Returns the parse modes supported for segments in this dialect.
    For most dialects, this is null because the converter internally handles the parsing of segments. But in particular for the GENERIC dialect, there are different parse modes. This returns a String[] containing each parse mode. Each string contains the SEF-serialization character followed by a tab followed by the description. It is possible in the future more options will be added, so the string should first be split by tabs.
    Example return: { "D\tDelimited", "F\tFixed-width", "R\tRegular expression" }.
    If the converter handles the parse modes completely internally, null is returned.
  • The GENERIC dialect supports a new data type, POSTAL. This type automatically breaks apart City/State/Zip or City/Province/Postal into component parts for both United States and Canadian addresses. The address is broken into five components: the city, the state/province abbreviation, the state/province name, the zip or postal code, and the country. For example, the input "Bedford, Mass 017301414" might produce something like this:
    <ADDRESS02>
        <ADDRESS0201>Bedford</ADDRESS0201>
        <ADDRESS0202>MA</ADDRESS0202>
        <ADDRESS0203>Massachusetts</ADDRESS0203>
        <ADDRESS0204>US</ADDRESS0204>
        <ADDRESS0205>01730-1414</ADDRESS0205>
    </ADDRESS02>
    This works bidirectionally, so that the XML above would produce a single value "Bedford, MA 01073-1414". As a side-effect of parsing, the formatting is cleaned up, with the appropriate punctuation supplied.
  • There is a new URI property called nd=sef|yes|no for "Require unique segment identifiers".
    The SEF file supports a new flag on .STD, called "ND". The syntax is that a ",ND" is added to the end of the string, so for example ".STD ,ND" would be proper. This flag was added by Foresight Technologies right before their acquisition by TIBCO, and is undocumented. However, it is used in certain types of GENERIC conversions.
    Because we recognize that not all tools understand this new flag, this nd= flag acts as an override.
    • nd=sef means to use the value from the SEF file, if present.
    • nd=no is the same as not having the "ND" flag set, and means to operate against segments by trying to match the prefix name or text pattern.
    • nd=yes means that there is no designator in the file that defines the syntax, and the parser should simply try the next segment in the message definition.
  • This build has been qualified against Java version 6, 7 and 8.
• Build 1893u
  • Added support for EDIFACT versions D13A and D13B
  • Error code 11 ‘invalidate date or time’ has been split into two cases, 11 ‘invalid date or datetime’ and 16 ‘invalid time’. This allows better reporting diagnostics and more accurate response messages when analyzing X12.
  • The following new errors are reported; formerly most were reported as 65 ‘expected this value but saw that value’.
  • 201: The interchange identifier in the header (%1) and trailer (%2) do not match ("%3" vs. "%4").
  • 202: The group identifier in the header (%1) and trailer (%2) do not match ("%3" vs. "%4").
  • 203: The message identifier in the header (%1) and trailer (%2) do not match ("%3" vs. "%4").
  • 204: Missing or invalid interchange identifier "%1".
  • 205: Missing or invalid group unique identifier "%1" in group number %2.
  • 206: Missing or invalid message unique identifier "%1" in message number %2.
  • 207: The count of groups in the interchange is actually %1 but the interchange trailer (%2) incorrectly states %3.
  • 208: The count of messages in the group is actually %1 but the group trailer (%2) incorrectly states %3.
  • 209: The count of segments in the message is actually %1 but the message trailer (%2) incorrectly states %3.
  • 210: Group identifier "%1" already seen in group number %2.
  • 211: Message identifier "%1" already seen in message number %2.
  • 212: Message "%1" does not belong to functional group "%2" but should be one of "%3".
  • 213: Unbalanced start/end segments "%1" seen %2 times, but "%3" seen %4 times.
  • 214: Functional group "%1" not recognized.
  • 215: Agency code "%1" not recognized.
  • 216: Unmatched LS/LE pair "%1" vs "%2".
  • 217: Unknown control standards identifier or agency code "%1".
  • 218: Expected to see codelist %1 but instead saw codelist %2.
  • X12-style errors in the analysis report are much more accurate. Prior to this release, many would be grouped under a generic message such as ‘one or more segments is incorrect.’
  • In some cases, autofill was correcting problems even when turned off. This was primarily the ISA I10/I65 element and the dates and times in ISA and GS segments, all for X12 and HIPAA. This caused the analysis report to miss items because they were being silently fixed.
  • In the analysis XML, if a native table and native code for an error is issued, the text explaining that error now is included in a new <NativeError> element instead of inconsistently being added to the textual explanation of the error.
  • When generating an X12-style response, any incorrect values being copied to the response are truncated if their length exceeds that set by the standard.
  • X12 responses now properly include comments if EDI comment generation is not disabled, making it easier to understand the response output.
  • The new “blank=yes|no” URI property determines whether an element whose content consists solely of whitespace is considered as “present” for purposes of mandatory checking. “blank=yes” means blank values count as mandatory content. blank=no means they do not. The default is “blank=yes”, unless “strict=yes”, in which case the default is “blank=no”.
  • A problem was fixed where X12 numeric values that exceeded their defined length were not always raising an error condition, even when “len=yes” was specified.
  • The GENERIC converter adds support for the new datatypes LITERAL, INET4ADDR, INET6ADDR and UUID.
  • The new “nodata=keep|drop” URI property controls whether rows that contain no data are emitted by the GENERIC converter. “nodata=drop” is the default.
  • There is a new “collapse=yes|no|spaces” URI property for the GENERIC converter.
    • “collapse=yes” means treat consecutive delimiters as if there was only one instance.
      As an example, “collapse=yes” means that “abc,,,def” would be treated as two values “abc” and “def”.
    • “collapse=no” means that consecutive delimiters indicate empty values.
      For example, “collapse=no” means that “abc,,,def” would be treated as five values, “abc”, “”, “”, “” and “def”.
    • “collapse=space” means collapse spaces, but treat any other consecutive delimiters normally.
• Build 1893t
  • Fixed 997/999 responses in X12 analyze report to include XML for nested groups properly.
  • Corrected some entries in the mapping table between internal error codes and X12 error codes.
  • TA101 is now padded to nine digits.
  • When auto=never is set, treat empty, mandatory fixed-width dates and times as invalid.
  • Fix length calculation of string conversion when special character fields contain control characters.
• Build 1893s
  • When using “EBCDIC” encoding with Custom XML Converters, COMP-3 values ending in “8” or “9” no longer lose the last digit.
• Build 1893r
  • Using rtrim=always no longer throws a NullReferenceException when going from XML to X12 EDI.
  • Parsing deeply-nested HL7 no longer throws an UnsupportedOperationException when incoming data does not exactly match the predefined message structure.
• Build 1893q
  • A chr= URI property, when used in a SEF file, is no longer ignored.
  • The check for maximum length was mistakenly included the decimal point when converting from XML to TELCO EDI, causing some values to trigger error messages when in fact they were within the limit.
  • The TELCO EDI representation now removes all leading zeroes for fixed-place decimals. Formerly, only insignificant zeroes to the left of the decimal were removed. While both behaviors are allowed by the specification, the new behavior is recommended.
• Build 1893p
  • The repeat count for the DMG05 element in X12 and HIPAA was not set in the repository. The workaround had been to set the value to 10 using a SEF file. The value of the repeat count is now incorporated into the repository. The incorrect repeat count affected the following versions of X12 and HIPAA: 004030, 004040, 004041, 004042, 004050, 004060, 005010, 005020, 005030, and 005040.
  • EDIFACT “A” and “AN” data types now respect minimum length when the len= URI property is set. Formerly, they were automatically padded with spaces to the minimal length. However the spaces would then be removed during EDI serialization, circumventing the error message.
  • Negative values are now handled properly when converting from XML to TELCO EDI.
  • Values less than one with leading zeroes are now handled properly when converting from XML to TELCO EDI.
• Build 1893n
  • Fixed ArrayOutOfBoundsException when toss characters are set to quotes in .conv file
• Build 1893m
  • Handled licensing better for workstations with more than four CPUs, including hyperthreading
• Build 1893k
  • Fixed “floating” CLM segment in HIPAA
  • Added in missing loop indicator to Analyze output
• Build 1893j
  • A doubled IEA segment in X12 should throw an exception
• Build 1893i
  • When processing from SAX or StAX input, do not throw NPE if StartDocument is not called
  • toobig= URI property now set for wide rows in autoconfig GENERIC .sef files
  • Properly pad AL3 values with ‘ ’ in control groups
  • Support toobig= in GENERIC runtime engine
  • Allow HL7 DateTime to use ‘ ’ as well as ‘T’ to separate date and time
• Build 1893h
  • Better handle interleaved segment groups in AL3
  • Expand address cache properly in AL3 for wide records
  • Allow HL7 Dates, Times and DateTimes to have ‘-’ or ‘:’ separators
  • Added repository data for X12 006030 and 006040
  • Added repository data for EDIFACT D11B, D12A, D12B
  • Added repository data for IATA 11-1, 12-1
• Build 1893g
  • Support TA1 in X12 and HIPAA Analyze responses via new ta1= URI property
  • Earlier changes back to 1893a are for support of DXSI

Installation

Notes about installation:

• During installation, a progress bar is displayed on the screen. If you choose to cancel the installation before it is complete, files that have already been copied to your machine are not removed. You must delete these files manually from the product installation directory.
• The DataDirect XML Converter installer accepts multiple product keys. For more information, refer to the DataDirect XML Converters for Java Installation Guide.

Using the Online Documents

The PDF books are an installable option for DataDirect XML Converters. You can view the PDF books with Adobe Reader. For instructions on how to use the online documents and Adobe Reader, refer to the Preface in the DataDirect XML Converters for Java Installation Guide.

NOTE: To download Adobe Reader from the Web, go to Adobe’s Web site at http://www.adobe.com.

DataDirect XML Converters Files

The following files are placed in the installer directory when you extract the contents of the 62_xmlconverters.jar file:

• 3rdPartySoftware.txt — Third-Party license restrictions
• ddxmlconvertersj.jar — File used to install DataDirect XML Converters
• installer.properties — Properties for the Java installer
• license.htm — The End User License Agreement (EULA)
• README.htm — This file
• XMLConvertersInstaller.jar — File containing the installer
• ExtensionTool.jar — Evaluation extension utility

When you install DataDirect XML Converters, the installer copies the following directories and files to the product installation directory (as determined by the user), represented here as “INSTALL_DIR”.

To INSTALL_DIR/

• 3rdPartySoftware.txt — Third-Party license restrictions
• fixes.txt — Fixes to known issues in the current release
• license.htm — The End User License Agreement (EULA)
• README.htm — This file

To INSTALL_DIR/doc (optional components)

• books.pdf — Bookshelf for the DataDirect XML Converters product documentation
• quickstart.pdf — Information on getting started with DataDirect XML Converters
• xmlconverters-ig.pdf — DataDirect XML Converters Installation Guide
• xmlconverters-ug.pdf — DataDirect XML Converters User’s Guide and Reference

To INSTALL_DIR/examples (optional components)

• demo.bat — Batch file for running the example
• demo.java — The demonstration file used in the example
• demo.sh — Shell script for running the example
• Numerous supporting files for file conversion examples

To INSTALL_DIR/help (optional components)

• help.htm — Launch file for the HTML documentation
• Numerous supporting files for the HTML version of the product documentation

To INSTALL_DIR/javadoc (optional components)

• index.html — Launch file for the Javadoc
• Numerous supporting files for the Javadoc

To INSTALL_DIR/lib

• XMLConverters.jar — DataDirect XML Converters Classes
• EDI.jar — Internal resource file for XML Converters
• /codehaus/*.* — Jar files for XML streaming libraries

Note that the /codehaus directory can be omitted if running with Java SE 6 or higher. They are only needed for running with J2SE 5 because J2SE does not include the StAX classes.

Third-Party Licensing Agreements

DataDirect XML Converters include JSON which is subject to the following license:

The JSON License

Copyright © 2002 JSON.org

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The Software shall be used for Good, not Evil.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

===============================================================

DataDirect XML Converters include Java HTML Tidy - JTidy which is subject to the following license:

Java HTML Tidy - JTidy

HTML parser and pretty printer

Copyright © 1998-2000 World Wide Web Consortium (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.

Contributing Author(s):

•      Dave Raggett <dsr@w3.org>
•      Andy Quick <ac.quick@sympatico.ca> (translation to Java)
•      Gary L Peskin <garyp@firstech.com> (Java development)
•      Sami Lempinen <sami@lempinen.net> (release management)

The contributing author(s) would like to thank all those who helped with testing, bug fixes, and patience. This wouldn’t have been possible without all of you.

COPYRIGHT NOTICE:

This software and documentation is provided “as is,” and the copyright holders and contributing author(s) make no representations or warranties, express or implied, including but not limited to, warranties of merchantability or fitness for any particular purpose or that the use of the software or documentation will not infringe any third party patents, copyrights, trademarks or other rights.

The copyright holders and contributing author(s) will not be liable for any direct, indirect, special or consequential damages arising out of any use of the software or documentation, even if advised of the possibility of such damage.

Permission is hereby granted to use, copy, modify, and distribute this source code, or portions hereof, documentation and executables, for any purpose, without fee, subject to the following restrictions:

1. The origin of this source code must not be misrepresented.
2. Altered versions must be plainly marked as such and must not be misrepresented as being the original source.
3. This Copyright notice may not be removed or altered from any source or altered source distribution.

The copyright holders and contributing author(s) specifically permit, without fee, and encourage the use of this source code as a component for supporting the Hypertext Markup Language in commercial products. If you use this source code in a product, acknowledgment is not required but would be appreciated.

===============================================================

DataDirect XML Converters include juniversalchardet - which is subject to the following license:

juniversalchardet

juniversalchardet is a Java port of ‘universalchardet’, that is the encoding detector library of Mozilla.

http://code.google.com/p/juniversalchardet/

The original code of universalchardet is available at http://lxr.mozilla.org/seamonkey/source/extensions/universalchardet/

Techniques used by universalchardet are described at http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html

Version: MPL 1.1/GPL 2.0/LGPL 2.1

The contents of this file are subject to the Mozilla Public License Version 1.1 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.mozilla.org/MPL/

Software distributed under the License is distributed on an “AS IS” basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License.

The Original Code is Mozilla Universal charset detector code.

The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by the Initial Developer are Copyright (C) 2001 the Initial Developer. All Rights Reserved.

Contributor(s):

• Shy Shalom <shooshX@gmail.com>
• Kohei TAKETA <k-tak@void.in> (Java port)

Alternatively, the contents of this file may be used under the terms of either the GNU General Public License Version 2 or later (the “GPL”), or the GNU Lesser General Public License Version 2.1 or later (the “LGPL”), in which case the provisions of the GPL or the LGPL are applicable instead of those above. If you wish to allow use of your version of this file only under the terms of either the GPL or the LGPL, and not to allow others to use your version of this file under the terms of the MPL, indicate your decision by deleting the provisions above and replace them with the notice and other provisions required by the GPL or the LGPL. If you do not delete the provisions above, a recipient may use your version of this file under the terms of any one of the MPL, the GPL or the LGPL.

===============================================================

This release of DataDirect XML Converters includes WoodSToX which is distributed under the Apache Software License, reproduced below:

Apache License, Version 2.0, January 2004

http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

“License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

“Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

“Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

“You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.

“Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

“Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

“Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

“Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

“Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.”

“Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices stating that You changed the files; and

(c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

(d) If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

===============================================================

Notice for Salesforce Application Developers

This notice is applicable when DataDirect XML Converters are used to access a Salesforce.com system. DataDirect XML Converters may be utilized directly or indirectly (i.e., through the use of one or more other applications utilizing DataDirect XML Converters) to transmit User Data outside of the Salesforce.com (SFDC) system. To the extent such transmission occurs, neither DataDirect nor SFDC are responsible for the privacy, security or integrity of that User Data. “User Data” means electronic data or information submitted by SFDC’s customers into SFDC’s system.

November 2020
End of README