SSDN - XML->EDI: inconsistent treatment of white space

XML Editor

Sign Up

Search

Options

Chat

Help

News

Log in

Not Logged in

Topic

Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Edward Scott

Subject: XML->EDI: inconsistent treatment of white space
Author: Edward Scott
Date: 03 May 2007 03:07 PM
Originally Posted: 03 May 2007 03:02 PM

EDIT: Sorry, this message board appears to trim white space, which in this case is not very helpful. In my XML and EDI samples I have replacedall space characters with a ·, so please interpret that character as a space (Hex 20).

hi,

I am using a trial version of stylus studio to convert XML to EDI. The java code I am using to do so is almost identical to that in the StylusStudio examples. An excerpt follows, where 'in' is the file path of the input xml and 'out' is the file path of the output edi:

Converter fromXML = ConverterFactory.newInstance().newConvertFromXML("adapter:EDI");
fromXML.convert(new StreamSource(in), new StreamResult(out));

Some places StylusStudio is good about preserving white space. For instance, I have an ISA segment which begins as follows in my XML:

<ISA>
<ISA01>00</ISA01>
<ISA02>··········</ISA02>
<ISA03>01</ISA03>
...
</ISA>

When StylusStudio converts this message the white spaces is preserved: ISA*00*··········*01...~

The elipsis indicates omitted data; it is not in my XML or in the EDI that StylusStudio produces.

In another case I have a segment in which my white space is being removed. For example, the XML for an NM1 segment is as follows:

<NM1>
<NM101>IL</NM101>
<NM102>1</NM102>
<NM103>SMITH</NM103>
<NM104>ROBERT</NM104>
<NM105>B</NM105>
<NM108>ZZ</NM108>
<NM109>··</NM109>
</NM1>

When StylusStudio converts this to an EDI message I end up with the following:

NM1*IL*1*SMITH*ROBERT*B***ZZ*~

When I am expecting the following:

NM1*IL*1*SMITH*ROBERT*B***ZZ*··~

Is this correct behavior? Why is it inconsistant between the ISA segment and the NM1?

Tony Lavinio

Subject: XML->EDI: inconsistent treatment of white space
Author: Tony Lavinio
Date: 03 May 2007 04:58 PM

There is no inconsistency.

In the ISA segment, the elements are defined as having fixed widths,
so they must be padded out.

But for every other element, the following rule kicks in. (This is
the one for strings; numbers have a similar rule.)

3.5.1.4 String
A string data element is a sequence of any characters from the basic
or extended character sets and contains at least one non-space
character. The significant characters shall be left justified. Leading
spaces, when they occur, are presumed to be significant characters. In
the actual data stream trailing spaces should be suppressed. The
representation for this data element type is AN.

So notice that trailing spaces are to be suppressed.

Edward Scott

Subject: XML->EDI: inconsistent treatment of white space
Author: Edward Scott
Date: 03 May 2007 05:03 PM

>In the ISA segment, the
>elements are defined as having
>fixed widths,
>so they must be padded out.

Correct. But according to the specs I am using (which can be found at the HIPAA Electronic Reading Room: http://www.ihs.gov/AdminMngrResources/HIPAA/docs/x092.pdf), the NM109 has a minimum length of 2. So shouldn't that be padded out also?

Tony Lavinio

Subject: XML->EDI: inconsistent treatment of white space
Author: Tony Lavinio
Date: 04 May 2007 10:30 AM

Yes, but that only applies to mandatory (M) elements.
Since NM109 is not mandatory, the proper way to show
that the value is not present is to omit it, not to
pad it out.

The reason the ISA segment is special is because some
of the special control symbols are in the line at certain
positions. So EDI parsers expect always to find:
- the data element separator at position 3,
- the data repetition character at position 82 (00402 and higher only),
- the component data element separator at 104, and
- the segment terminator character at 105.

If the elements in that first ISA record were not fixed,
the parser wouldn't know where to find those symbols.

Edward Scott

Subject: XML->EDI: inconsistent treatment of white space
Author: Edward Scott
Date: 04 May 2007 12:05 PM

>Yes, but that only applies to
>mandatory (M) elements.
>Since NM109 is not mandatory,
>the proper way to show
>that the value is not present
>is to omit it, not to
>pad it out.

OK, this is starting to make sense. Now, while NM109 is not mandatory (M), it's not optional (O) either. It's requirement designator is X, and according to the syntax notes, "if either NM108 or NM109 is present, then the other is required."

I do have a NM108 present, so shouldn't that cause NM109 to be required?

Tony Lavinio

Subject: XML->EDI: inconsistent treatment of white space
Author: Tony Lavinio
Date: 04 May 2007 01:04 PM

Yes but no. ;)

Where possible, truncating spaces still trumps all but the
actual (M)andatory attribute.

Edward Scott

Subject: XML->EDI: inconsistent treatment of white space
Author: Edward Scott
Date: 04 May 2007 01:30 PM

Well then, I am presented with a problem. The EDI that StylusStudio is generating from my XML is not valid. Either I have an NM108 but no NM109, or I have an NM109 that doesn't satisfy the minimum length requirements.

Is there an option in the StylusStudio converter to prevent the truncating of white space? Or is there some attribute I can add to XML element to prevent truncating white space on that particular element?

Tony Lavinio

Subject: XML->EDI: inconsistent treatment of white space
Author: Tony Lavinio
Date: 04 May 2007 02:05 PM

That's an interesting question, and frankly one that's not come up.
We'll do some research and let you know shortly.

Edward Scott

Subject: XML->EDI: inconsistent treatment of white space
Author: Edward Scott
Date: 15 May 2007 04:55 PM

Did you manage to find anything in your research?

Tony Lavinio

Subject: XML->EDI: inconsistent treatment of white space
Author: Tony Lavinio
Date: 17 May 2007 03:50 PM

I have two different strategies.

1) Redefining the element to be mandatory so that it doesn't
trim the space,

2) Allowing support of an extra attribute, like xml:space, to
be recognized.

Do you have a sample EDI file we can use to make sure we've got
your scenario covered? You can post it here as an attachment or
email it to stylus-field-report@progress.com.

Edward Scott

Subject: XML->EDI: inconsistent treatment of white space
Author: Edward Scott
Date: 17 May 2007 04:10 PM

I have recently spoken with the people we are sending the EDI messages to. The appropriate thing for me to do here is to actually leave out both the NM108 and the NM109 if the NM109 is blank.

In fact, nowhere beyond the ISA segment will I need to include a field consisting entirely of spaces. So stylus studio's behavior will work just fine.

Thank you for looking into this, and thank you for being patient. I am new to EDI, so I appreciate your explanations.

Alex Guarneri

Subject: XML->EDI: inconsistent treatment of white space
Author: Alex Guarneri
Date: 12 Sep 2007 06:13 AM

Tony,
We are facing a similar problem.

When a this tag is processed from XML to EDI
<IMD0304 xml:space="preserve">Attività e virtù. Anima e corpo in </IMD0304>
the trailing space after "in" is truncated.
Putting the xml:space attribute doesn't seem to work either.

Any suggestions?

Thankl you.

Alessandro

Tony Lavinio

Subject: XML->EDI: inconsistent treatment of white space
Author: Tony Lavinio
Date: 12 Sep 2007 09:38 AM

In your case, we are doing the correct thing.
According to the EDIFACT standard at
http://www.unece.org/trade/untdid/texts/d422_d.htm,
it says regarding white space:

7. COMPRESSING

In data elements for which the Data Elements Directory specifies
variable length and there are no other restrictions, insignificant
character positions shall be suppressed. In the case of insignificant
characters, leading zeroes and trailing spaces shall be suppressed.

Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

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 to Conference:

Log In Options Username: Password:

Site Map | Privacy Policy | Terms of Use | Trademarks

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.