|
|
 next
|
  Subject: converter EDI --> typ = no
Author: Tony Lavinio
Date: 11 Aug 2009 05:57 PM
|
First, the issue is not with typ=no, but in your query. The query
line:
where $MEA/MEA02/MEA0201/text() = 'G'
should be
where $MEA/MEA02/text() = 'G'
But there is a more subtle problem in your XQuery.
saying "$lmnt instance of xs:decimal" depends on the declared type of
the element based on XML Schema, not based on whether the string value
of the element looks like a number.
So without an XML schema defined, "instance of" will not do what you
expect. If you want to test if an untyped element looks like a number,
use this:
string(number($lmnt)) != 'NaN'
In any case, this should not be needed. The XML Converters already
have builtin code to check for all sorts of conditions, including
whether a specific element has the correct characters for that
datatype and minimum and maximum lengths.
One issue your code does not test is the proper way of handling
lengths for numeric values. For example, the '-' sign is not counted
as part of the length, ".5" and "5." are illegal values, etc. The
converter handles all of these issues, but you are for some reason
disabling those checks and handling them manually.
Possibly a better method would be to intercept the errors via a
EDIConverterListener Java class, and reporting your own errors. This
would let the converters handle their validation as designed, and
would save you duplicating much effort.
|
|
next
|
  Subject: converter EDI --> typ = no
Author: DG Sarbo
Date: 12 Aug 2009 04:40 AM
|
>No, I am not wrong, based on
>the sample1.edi and
>sample2.edi
>that you posted earlier.
>Neither has a +:G+, but both
>have just
>+G+.
Yes you are wrong... I know for a FACT that it MUST be MEA/MEA02/MEA0201
Just open the D95B EDIFACT standard... see that it has a composite element and look inside it to see that the 'G' is in 'MEA0201'.
It is impossible to have a composite element (like MEA02) with a string/AN value (like 'G').
If you think this:
>Perhaps the real definition
>uses +:G+, but that's not the
>sample
>you posted, and that's why
>your sample didn't work.
Than you did not try my xquery in SS. If you change the code like you suggested the 'G' will not be found and the code would not reach the part where the local:checkField function is.
On the other hand if you do it like I wrote the code, than the function is reached (as you can try for yourself), executed and the error message that is in it, is displayed by SS (in the error message the value of MEA/MEA03/MEA0302 is displayed, this could not happen if my code was wrong!!!)
EDIFACT works like this:
if there is a composite element and a value from the first composite (like I said: 6313) holds 'G' than there is no need to use '+:' in a EDIFACT message. That is why I said: "it can be seen as"
If the 'G' would be in the 2nd/ 3d of 4th composit (in: 6321, 6155 or 6154) than the ':' would be used.
Please just try running the xquery before stating something that is not true.
|
|
|
|
|
sample1.xquery
top