XSD Validation Failed in NoticeSubType 7

[rengit62]

Hi Labs !
I updated my code following EFORMS Notice Editor , but the notice made in this way has got a validation error in this section :
cac:TenderingProcess
cbc:GovernmentAgreementConstraintIndicatorfalse</cbc:GovernmentAgreementConstraintIndicator>
cac:ContractingSystem
<cbc:ContractingSystemTypeCode listName="framework-agreement">fa-wo-rc</cbc:ContractingSystemTypeCode>
<cbc:ContractingSystemTypeCode listName="dps-usage">dps-nlist</cbc:ContractingSystemTypeCode>
</cac:ContractingSystem>
</cac:TenderingProcess>

the 'correct' section should be :
cac:ContractingSystem
<cbc:ContractingSystemTypeCode listName="framework-agreement">fa-wo-rc</cbc:ContractingSystemTypeCode>
</cac:ContractingSystem>
cac:ContractingSystem
<cbc:ContractingSystemTypeCode listName="dps-usage">dps-nlist</cbc:ContractingSystemTypeCode>
</cac:ContractingSystem>

In fact in xsd ContractingSystem is unbounded :
<xsd:element ref="cac:ContractingSystem" minOccurs="0" maxOccurs="unbounded"/>

while for ContractingSystemTypeCode maxOccurs = 1
<xsd:complexType name="ContractingSystemType">
xsd:sequence
<xsd:element ref="ext:UBLExtensions" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="cbc:ID" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="cbc:ContractingSystemTypeCode" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="cbc:Description" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>

I am using sdkVersion" : "1.6.0 , should I update sdk ?
Thanks and Regards
Renato

[YvesJo]

Hi Renato,
Notice editor shouldn't be used as a paradigm as it is still under development and may have some limitations not yet addressed. Behavior should preferably be extracted from the JSON files. Most non-repeatable fields in repeatable nodes are properly described and shouldn't cause any trouble.

[rengit62]

OK Yves
let me ask a simple question.
In Notice Editor, from the xpathRelative of every field the predicate is first removed, splitted by "/" in parts, and every part is 'candidate' to became an Xml tag.
But before making the xml tag, with every part, this time togheter with the predicate, an Xpath search is done in the actual Xml to verify that
the tag is already present.
If it is already present the tag is not built again.

If this is not a paradigm, can you tell me please, which the right paradigm ?
Perhaps , not always the Xpath search should be done ? If Yes by which condition ?
Thanks a lot
Renato

[YvesJo]

Hi Renato,
I understand the algorithm but am not able to help here as I did not deal with the XML generation. I know that Notice Editor is not as mature as eNotices2 and some situations problematic with Notice Editor aren't with eNotices2, There are however few problematic cases for both which the nodes definition may need an update.

[rengit62]

Hi Yves
today I found a similar problem with node ND-WinningParty.
The problem is to understand what to do with Xpath predicate of a node or a field. As you do not deal with XML generation, do you mind to ask to your colleagues ?

[YvesJo]

Hi Renato,
Predicates have been added to help differentiates nodes by adding some context, that could be confused with other ones in their absence. this shouldn't impact the generation, as the defined group should be sufficient. For the identified case, there could be an issue, I will check for that. I will also let my colleagues know about it.

[rouschr]

I think the problem here is when it does not find the xpath relative element using xpath search relative to the parent node, it will start looking for the XML element "ContractingSystem" and it will find an existing one (for the second item you create). Maybe there are cases for which this behavior is desired.

    "xpathRelative" : "cac:ContractingSystem/cbc:ContractingSystemTypeCode[@listName='framework-agreement']",
    "xsdSequenceOrder" : [ { "cac:ContractingSystem" : 29 }, { "cbc:ContractingSystemTypeCode" : 3 } ],

To fix this the logic could be that when you are trying to build the ContractingSystem element of the relative path, do not try to reuse the existing found elements and always recreate intermediary elements (like ContractingSystem in this case). However I am not sure if this would break other cases if you do this.
The best for this would be to have more unit tests about the XML generation on such cases.
There is a similar problem for which we created a ticket: https://citnet.tech.ec.europa.eu/CITnet/jira/browse/TEDEFO-2206
I am working on several SDK 8 related features and will very likely not have time to work on the editor demo project for a while.
You can also do a PR if you are sure to find a way to fix this case without breaking other cases.

[rengit62]

Thanks you for your response Christophe,
just a question , in the actual demo project the xpathRelative is used to search by xpath if a tag already exists, and as you wrote ,
there are cases for which this behavior is desired.
But when there is a predicate , I found some cases where ,it seems to me, the search has to be done to test if a node ( or a field ) is rendered as xml tag or not.
Examples :
ND-WinningParty ("xpathRelative" : "efac:Company[(cac:PartyIdentification/cbc:ID/text() = //efac:TenderingParty/efac:Tenderer/cbc:ID/text()) or (cac:PartyIdentification/cbc:ID/text() = //efac:TenderingParty/efac:Subcontractor/cbc:ID/text())]", )
or
BT-708-Lot ("xpathRelative" : "cbc:LanguageID[not(../cbc:DocumentStatusCode/text()='non-official')]")
BT-737-Lot ("xpathRelative" : "cbc:LanguageID[../cbc:DocumentStatusCode/text()='non-official']")
which depend on the value of
OPT-050-Lot("xpathRelative" : "cbc:DocumentStatusCode")
It is true ? And if yes , it is always true ?
Thanks and Regards
Renato

[rouschr]

When you try to build the XML, the document should be considered fully valid at that point.
In the editor demo for now we only cover basic required (mandatory) fields.
Assuming you handle full validation before you try to build the XML.
Due to predicates the element position of some fields depends on the position of other fields.
This use of predicates works well when reading from XML for which it was initially designed (looking up fields in an existing notice).
I find it hard to use those "predicate heavy" xpaths when building the XML as it would mean you would first have to build what ever the field depends on (a sibling, ...) before you try to evaluate that xpath as otherwise the element could be there, but just added after you looked for it!
We had thoughts on providing extra information in addition to the predicates or in general to help with the XML generation.
Existing examples in the fields.json are "schemeName" and the "xsdSequenceOrder" which assist with XML generation and are not yet used by the editor demo.
For ND-WinningParty I am not sure what is happening, I will have to clarify with @YvesJo

[rengit62]

About the predicates, I agree with you, I knew them just to search on a existing xml.
Anyway as you put the predicate in some fields and node in fields.json , could you tell me how to use them ?
I mean when splitting the xpathrelative by "/" to make xml tag ?
Very good the xsdSequenceOrder, but you wrote 'Existing' , I did not find anything in fields.json

"ublVersion" : "2.3",
"sdkVersion" : "eforms-sdk-1.6.0",
"metadataDatabase" : {
"version" : "1.6.0",
"createdOn" : "2023-02-17T12:00:00"
It will be in the next release ?
Bye and Thanks
Renato