SSDN - Need help with unique particle attribution rule violation

XML Editor

Sign Up

Search

Options

Chat

Help

News

Log in

Not Logged in

Topic

DG Sarbo

Subject: Need help with unique particle attribution rule violation
Author: DG Sarbo
Date: 16 Jun 2009 06:51 AM

I get the follow validation problem with this code:

complex type 'CPD200_IN' violates the unique particle attribution rule in its components 'CTY' and 'CTY'

<xsd:sequence>
<xsd:element name="CTY" type="CTY" minOccurs="1" maxOccurs="1"/>
<xsd:element name="CTY" type="CTY" minOccurs="0" maxOccurs="1"/>
<xsd:element name="CTY" type="CTY" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>

Changing it to this does not help:

<xsd:sequence>
<xsd:element name="CTY" type="CTY" minOccurs="1" maxOccurs="1"/>
<xsd:element name="CTY" type="CTY" minOccurs="0" maxOccurs="1"/>
<xsd:element name="CTY" type="CTY" />
</xsd:sequence>

BUT... I don't get a violation when I change the code to:

<xsd:sequence>
<xsd:element name="CTY" type="CTY" minOccurs="1" maxOccurs="1"/>
<xsd:element name="CTY" type="CTY" />
<xsd:element name="CTY" type="CTY" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>

Can anyone help please?
See attachment for whole code

Ps. if I valdiate the above code in xml-spy it validates with no errors

problemcode.xml
Code with problem

codeok.xml
Code without problem

(Deleted User)

Subject: Need help with unique particle attribution rule violation
Author: (Deleted User)
Date: 16 Jun 2009 12:53 PM

Hi,
your schema does violate the "unique particle attribution rule", that evidently is not enforced by the other tool. In short, the rule enforces that each new XML node must be immediately associated with a single definition, with no lookahead.

In your first definition, in a sequence of two CTY nodes the first one is associated with minOccurs=1/maxOccurs=1 definition, but the second could be an instance of either the second or the third minOccurs=0/maxOccurs=1 definition.

In your second definition, the ambiguity for the second CTY node is always between an optional second definition or a mandatory third one.

In the third definition, you have no ambiguity because your schema requires two mandatory CTY nodes before allowing for an optional third.

Hope this helps,
Alberto

DG Sarbo

Subject: Need help with unique particle attribution rule violation
Author: DG Sarbo
Date: 17 Jun 2009 05:39 AM

Thank you Alberto!

I hope you could further help me out with this problem.

Normally we receive a message that is based on the edifact standard and any changes/extensions to the standard are put in a SEF file. We start the mappings of incoming messages with the EDI-to-XSD wizard… creating an XSD based on the incoming edi message, selecting a edifact standard extended by a SEF file. Then we create a scenario where we use a edi message that is xml-converted (extended with the SEF file). Then the mapping is done to a target XSD that our system uses.

Now we have a problem that a customer sends us a edi message that is not based on the edifact standard. They went ahead and created a message of their own...

My first thought was to create an XSD based on their message specification (see attachement in my first entry) and if I understand your explanation their specifications are incorrect. This issue is minor compared to the following problem:

I cannot add their edi message to a scenario as an input. The xml-converter does not recognize the message (because they did not use a standard edifact message) and if I understand correctly the extension with a sef file cannot be done.

If I use the following statement at the scenario input:

“converter:EDI:opt=yes:ignore=3,9:user=file://C:\..\[myfile].sef?file:///c:/../[their message].edi”

I get “There is a mismatch between the segment definition and the number of elements or composite elements.”

Any thoughts on how I could solve this issue?

Tony Lavinio

Subject: Need help with unique particle attribution rule violation
Author: Tony Lavinio
Date: 17 Jun 2009 09:06 AM

Either the SEF file needs to be updated to match the input, or you
could use the URI count= option to disable the segment count checking.

See http://www.xmlconverters.com/doc/41/java/xmlconverters_ug/wwhelp/wwhimpl/common/html/wwhelp.htm?context=DataDirect_XML_Converters_User_s_Guide_and_Reference&file=reference8.html

Probably doing count=multi would work best for you.

DG Sarbo

Subject: Need help with unique particle attribution rule violation
Author: DG Sarbo
Date: 05 Aug 2009 10:01 AM
Originally Posted: 03 Aug 2009 10:26 AM

This does not help.

I think the problem is caused because XML and EDI have different data models. XML has the UPA rule and EDI does not.

In EDI I can use an RFF segment in a message that is mandatory and than have two more RFF segments that are optional. If I use the same code in XML it throws an UPA violation.

This is ok in EDI ( after the ---> is what is in the SEF file):

RFF+VM:CNA2279' ---> M
RFF+AM:DNA1239' ---> O
RFF+DM:RNA2321' ---> O

But in XML it is wrong:

<xsd:element name="RFF" type="RFF" minOccurs="1">
<xsd:element name="RFF" type="RFF" minOccurs="0">
<xsd:element name="RFF" type="RFF" minOccurs="0">

So when there is a mapping and the result needs to be validated against an XML it will not work in SS.

It is possible to do the validation in the XQuery, but there is a problem. Every time there is a incoming EDI message the Xquery has to be executed before the error in the EDI is noticed...

I think validating before execution beats validation while executing.

Edit:
the above example is does not illustrate the problem because it can be rewritten to:

<xsd:element name="RFF" type="RFF" minOccurs="1">
<xsd:element name="RFF" type="RFF" minOccurs="0" maxOccurs="2">

The problem is illustrated by the following:

<xsd:element name="DTM" type="DTM" minOccurs="0"/>
<xsd:element name="DTM" type="DTM"/>

This cause the UPA rule to fire.

Tony Lavinio

Subject: Need help with unique particle attribution rule violation
Author: Tony Lavinio
Date: 03 Aug 2009 11:24 PM

We don't recommend using XSD files to validate EDI ever.

The EDI Converters already do most of the validating. For
anything they don't handle, we recommend using XQuery.

XSD is just not sufficiently powerful to handle EDI; we
really only recommend it for mapping purposes.

DG Sarbo

Subject: Need help with unique particle attribution rule violation
Author: DG Sarbo
Date: 04 Aug 2009 02:37 AM
Originally Posted: 04 Aug 2009 02:30 AM

EDI can be validated with a dictionary... a dictionary is very much the same as XSD.

Here is a part of a .dic file:

<CompositeElement ID="C506" Name="Reference" Req="M" MaxUse="1">
<ComponentElement ID="1153" Name="Reference qualifier" Req="M" MaxUse="1" Type="AN" MinLength="1" MaxLength="3"/>

I have put the whole .dic file that we used to validate with in GoXML and the XSD that we would use in SS.

xsdexamplefileA.xsd

dictionaryexamplefileA.dic.txt
rename to .dic (delete .txt at the end)

Tony Lavinio

Subject: Need help with unique particle attribution rule violation
Author: Tony Lavinio
Date: 05 Aug 2009 12:49 AM

The XML converters have the ability to perform similar validation
already for element position, type and content. The only part
they don't do internally is handle the conditions like
Type="1153=='SSX'", which XSD also cannot handle.

Internally the converters have many of the definitions already,
and the equivalent of the .txt file is the .sef file.

We use XQuery to handle the co-occurence constraints, like
Type="1153=='SSX'"

DG Sarbo

Subject: Need help with unique particle attribution rule violation
Author: DG Sarbo
Date: 05 Aug 2009 10:15 AM
Originally Posted: 05 Aug 2009 03:12 AM

I don't see your point.

We have always done validation with an XSD/dictionary in our old mapping tool.

With our new tool, SS, we wanted to do validation with the converters, or with an XSD (--> doc wizard, with an EDI/SEF).

Because the converters/xsd builder cannot handle all EDI/SEF combo we are forced to do it with XQuery.

We don't want e.g. 60% of our validation with converters/XSD's and 40% within a XQuery, we want to handle that in one place/file, so when changes occur to our services we know where to look.

I am not saying SS is a bad tool or anything (I like working with it very much). I am just saying that the converters cannot handle everything that is possible in EDI... I have given enough examples already of this. Because we have a uniform way of working, we do all our validation in one place (in the XQuery). So we have no real use of the build in converters (we are pretty unhappy about this).

The converters should handle anything/everything of EDI, and if not, it should be made very clear from the beginning that there are things in the XML datamodel (like UPA) that cause problems when working on a mapping.

Edit:
EDIFACT is not a language, users can redefine it any way they want. It is possible to have a redefinition of a segment (e.g. RFF, Mandatory, length 35 and later in the message RFF, Mandatory, length 25. Or Another example: It should be possible to have 2 DTM segments of which the first is optional and the second is mandatory).

Tony Lavinio

Subject: Need help with unique particle attribution rule violation
Author: Tony Lavinio
Date: 05 Aug 2009 10:58 AM

Rather than respond hastily, we're going to take some time internally
to review your questions and comments; we'll follow up next week.

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.