XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Stylus UserSubject: XML to EDI
Author: Stylus User
Date: 19 May 2008 10:52 PM
To test our EDI application for accuracy, I created an EDI XML document which I knew was invalid prior to saving it using the X12 converter (it didn't match the spec, but was valid according to the schema), but the tool failed to catch the error.

I wanted to test the support for numeric values. I put a decimal value in a field specified as n0 in the X12 specification.

Stylus Studio allowed me to SAVE it, as the file ended up on disk in the invalid state (with a decimal point).

Upon trying to READ the file, the open did fail with an error message.

I expected the SAVE routine to catch the problem and convert the decimal value to the proper state before saving the EDI X12 document to be transmitted.

Is this a problem with the converter, or should I be doing something differently? I have not yet tested date values, or values restricted to a list. Would I be able to save files with invalid dates and list values, too?

Postnext
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 20 May 2008 11:04 AM
It should catch it at save time, unless the URI option
to disable type checking is set.

Could you please tell us which version and build number
of Stylus Studio you are using?

Postnext
Stylus UserSubject: XML to EDI
Author: Stylus User
Date: 20 May 2008 12:16 PM
Sure, it's build 1050g, SS 2008. What appears to happen in SS is first it writes the invalid file (decimal in n0 field), then it attempts to read it back into the IDE. An error message comes up at that point, but from the stack trace it's clear that SS is reading the file, and it's also been completely written out to disk.

I just finished testing what happens when saving an XML file with a bad date field. The converter caught the invalid date as it was saving the file, but on disk was left a fragment of an EDI file, with data up until the time of the error. I put the invalid date in the GS segment, and what I found on disk was a file with only an ISA segment.

We're going to be going on to use the components from generated Java code, but we're doing preliminary testing in SS. What is important to us is that only good EDI files are sent and received, and getting invalid and incomplete files on disk is what we are trying to avoid. We'd like to see all validity checking done before anything is written to disk (at least in the destination folder).

If we have to write a temporary file, read it in order to check it, and then move it if the read is successful, I guess we would consider this an acceptable workaround, but the performance hit will be expensive.

Postnext
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 20 May 2008 12:43 PM
The converters are designed to work in streaming mode, so
unless your destination is a DOM or something that will
accumulate the entire file, an error will leave partial
output.

We could have accumulated the entire stream and then written
the output, but that breaks any possibility to pipeline.

By streaming and providing exception handling, we feel that
it allows the one embedding the converters (that is, you) to
choose how to best handle these conditions.

Note that you can send the output to memory; it doesn't have
to be a file. Both Java and .Net have methods to do this,
such as ByteArrayOutputStream or StringWriter.

But on the original question, it is wrong that we let a number
get written out with a wrong format. Just to make absolutely
sure we cover the case you are seeing, could you please email
the test file to stylus-field-report@progress.com?

Postnext
Stylus UserSubject: XML to EDI
Author: Stylus User
Date: 20 May 2008 01:10 PM
Sure, I'll send in the XML file, and the resulting EDI X12 file.

So I understand the design, could you tell me what happens within the EDI converter with numbers that come in with decimal points when the destination is an EDI field with implied decimal positions?

What would be ideal is to be able to send in XML the actual value, with conversion (multiplying, rounding, truncating, etc) happening in the converter.

We have the Java BigDecimal type mapped to the XML elements which are decimal in the schema, and it is quite likely these will serialize to text containing the decimal point in all cases, even when the value is a whole number, or when the destination has implied decimal positions in the X12 spec.

Postnext
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 20 May 2008 07:03 PM
The XML should show the explicit decimal point, since the
XML has no notion of implied decimals. The converter should
properly handle scaling on the way in and out to match the
n0 to n9 datatype of the number.

We did receive your test; we'll post back here when we have
an answer. Thanks for the test case.

Postnext
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 26 May 2008 10:58 PM
We've tracked down the problem; indeed when going from XML to EDI
the converter was scaling the number based on the n0..n9 setting,
but was not removing any decimal.

The next release includes a change so that this is handled properly.
Also, if the scaling produces a value which still has a decimal
fraction, a recoverable error will be signaled. The recovery mode
will be to truncate the portion after the decimal.

In your test case, the "1.0" would silently be turned into "1" in
the EDI.

Thank you again for the test case.

Postnext
Stylus UserSubject: XML to EDI
Author: Stylus User
Date: 27 May 2008 05:19 PM
Thank you. Could this be made available as a hotfix, or is the next version to be released soon? We have licensed the components.

Our object model has been generated from a series of schemas for documents we intend to support. If the N0 elements had been restricted as xsd:integer instead of xsd:decimal in the schema, we would not have identified this issue, because Integer.toString() would not contain a decimal point...

Would a change to the schema wizard be considered, to implement N0 fields using xsd:integer?

Postnext
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 02 Jun 2008 12:11 PM
A fix for this should be available shortly; we will contact you as
soon as it is through QA.

The fix will be for the converter; changing the code regarding the
generating of the schema is more invasive and wouldn't be a candidate
for a patch release. We'll look at emitting xs:integer for the next
release, though.

Postnext
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 03 Jun 2008 10:57 PM
This fix will be in the 1147d patch release; if you need an advanced
copy of the solution please contact us at stylus-field-report@progress.com
and we'll make arrangements.

Postnext
Stylus UserSubject: XML to EDI
Author: Stylus User
Date: 18 Jun 2008 03:16 PM
Thank you, I am testing these changes, and have a question. In ISA13 for example, the value I see in X12 is now an integer without the decimal point (great!), but padded with leading spaces... Is this correct?

It is my understanding that ISA13 is an N9 type (numeric only), which has a minimum length requirement of 9, so the padding should be leading zeros (not spaces).

Postnext
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 18 Jun 2008 05:57 PM
It looks like you're correct. :(

I looked in the documentation from X12 for 4010.

In X12.6 APPLICATION CONTROL STRUCTURE, in 3.5.1.1 Numeric, it
says:
"Leading zeros should be suppressed unless necessary to satisfy
a minimum length requirement."

We'll take care of this in the next release. Sorry for the
inconvenience.

Interesting that it made it this far without anyone else picking
up on it, and without breaking the many real-world test cases
we've used in our regression tests.

Postnext
Stylus UserSubject: XML to EDI
Author: Stylus User
Date: 18 Jun 2008 06:05 PM
Ok, thanks for checking into it. I would like to put an application into production. Do you think that the commercial translators will ignore the minor discrepancy, and thus I should not worry about sending X12 data out in this format for the time being?

Posttop
Tony LavinioSubject: XML to EDI
Author: Tony Lavinio
Date: 19 Jun 2008 12:37 AM
I hope so ;)

If there is a problem, contact us privately on
stylus-field-report@progress.com and we'll see
if we can make some special concession for you.

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.