|
|
 next
|
  Subject: ISA12 vs GS08
Author: Stylus User
Date: 26 May 2008 11:22 PM
|
Certainly, it would be my pleasure. We recently received a test file from a new EDI partner, where the ISA and GS versions were different. The ISA was version 00200 (ISA12), and the transaction set was version 004010 (GS08).
The resulting XML file did not validate against the schema for version 4010 because some of the ISA fields were renamed between versions (using the long names). Examples are ISA15 and ISA16: TestIndicator, SubelementSeparator to UsageIndicator, ComponentElementSeparator respectively.
From the translator, I did expect a file which would validate using the version assigned to the transaction (instead of the envelope). It sounds like the translator is more advanced than the schemas which can be generated for validation (we can only generate a schema using one version, but multiple versions can exist in the XML translation).
I'm going to discuss the issue with the partner, to see if I can get the versions to match. However, since the spec allows the two to be different, I can't assert their data is invalid.
|
|
next
|
  Subject: ISA12 vs GS08
Author: Tony Lavinio
Date: 27 May 2008 10:04 AM
|
> Certainly, it would be my pleasure. We recently received a test
> file from a new EDI partner, where the ISA and GS versions were
> different. The ISA was version 00200 (ISA12), and the
> transaction set was version 004010 (GS08).
First, although we "tolerate" 00200, just note that officially
our support for X12 starts at version 00303, as is noted at
http://www.xmlconverters.com/standards/x12 - but that isn't the
problem here.
> The resulting XML file did not validate against the schema for
> version 4010 because some of the ISA fields were renamed
> between versions (using the long names). Examples are ISA15 and
> ISA16: TestIndicator, SubelementSeparator to UsageIndicator,
> ComponentElementSeparator respectively.
Yes, that's true. The schemas that we generate are good for
mapping, but aren't really designed for validation. This is
because XML Schema doesn't have the functionality necessary to do
real validation. The testing done inside of the converters
themselves is far superior.
> From the translator, I did expect a file which would validate
> using the version assigned to the transaction (instead of the
> envelope). It sounds like the translator is more advanced than
> the schemas which can be generated for validation (we can only
> generate a schema using one version, but multiple versions can
> exist in the XML translation).
In those cases, probably the best solution would be to generate
two schemas and merge the relevant pieces. But again, we don't
support 0020x at this time - but as a concession to some of our
users, we "pretend" it is 00303.
> I'm going to discuss the issue with the partner, to see if I
> can get the versions to match. However, since the spec allows
> the two to be different, I can't assert their data is invalid.
Again, don't assume that if it passes XSD validation the data is
valid. There are a host of reasons why the XSD would say "okay"
when the EDI is wrong, or the XSD would say "yuck" when the EDI
is perfectly fine. For example:
1. Two part fields, like element 103.
2. Two different versions of the same transaction set in the
same file.
3. Field length maximums for numerics (some XSD validators
confuse the length of the 'value space' with that of the
'lexical space'.
4. Segment repeat counts (most XSD validators run out of
memory, so we are forced to say "maxOccurs=unbounded" instead
of using the actual value.
5. Hash and segment count values in trailer segments like CTT,
SE, GE and IEA.
This is why the main purpose of the schemas with the XML
Converters is for mapping, and not for validation. XML Schema
simply isn't powerful enough to do the job.
Hope this helps.
|
|
|
|
|
top