XML generation of ContractExecutionRequirement

[sbo2718]

Hi,

I have a question regarding the generation of ContractExecutionRequirement in the XML.
According to the documentation a new XML node should be created if
a) the node doesn't exist
b) the field/xmlStructure is marked as repeatable

Since .e.g. the following BTs are not marked as repeatable there is only one node 'ContractExecutionRequirement' created, but looking at the examples and. the XSD there should actually 2 separate nodes.

So my question is: How can I detect that I have to create a new node for the first segment of the xPath?

BT-743-Lot
"xpathRelative" : "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listName='einvoicing']"
"repeatable" : {
      "value" : false,
      "severity" : "ERROR"
    },

BT-736-Lot
"xpathRelative" : "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listName='reserved-execution']",
 "repeatable" : {
      "value" : false,
      "severity" : "ERROR"
    },

[YvesJo]

Hi,
Let’s consider these paths should be decomposed and an additional parent node should be defined for each of these fields.

For BT-743-Lot
Hypothesis: a Node should be defined and associated to cac:ContractExecutionRequirement[cbc:ExecutionRequirementCode/@listname='einvoicing']
This node is not repeatable as there may not be more than one cac:ContractExecutionRequirement element with einvoicing information inside
Hence, no node has to be defined which contradicts the hypothesis

For BT-736-Lot
Hypothesis: a Node should be defined and associated to cac:ContractExecutionRequirement[cbc:ExecutionRequirementCode/@listname='reserved-execution']
This node is not repeatable as there may not be more than one cac:ContractExecutionRequirement element with reserved execution inside
Hence, no node has to be defined which contradicts the hypothesis

Also consider that node repeatability is defined to deal with the number of occurences of a Group on the UI. (+/- buttons).

[sbo2718]

Where are you getting the xpath expressions with the predicates on the ContractExecutionRequirement from?
In the fields.json they are defined as in my original question.

So the flow is:
BT-743-Lot
cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='einvoicing']

Since neither of the nodes exits yet, a new node for ContractExecutionRequirement is created with the nested ExecutionRequirementCode, the xml looks like:

<cac:ContractExecutionRequirement>
<cbc:ExecutionRequirementCode listName="einvoicing">required</cbc:ExecutionRequirementCode>
</cac:ContractExecutionRequirement>

BT-736-Lot
cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='reserved-execution']

Since there is no predicate present on the ContractExecutionRequirement and the BT is not repeatable no new element is created and the existing node is used. Which means the xml looks like:

<cac:ContractExecutionRequirement>
<cbc:ExecutionRequirementCode listName="einvoicing">required</cbc:ExecutionRequirementCode>
<cbc:ExecutionRequirementCode listName="reserved-execution">no</cbc:ExecutionRequirementCode>
</cac:ContractExecutionRequirement>

While it should look like

<cac:ContractExecutionRequirement>
<cbc:ExecutionRequirementCode listName="reserved-execution">no</cbc:ExecutionRequirementCode>
</cac:ContractExecutionRequirement>
cac:ContractExecutionRequirement
<cbc:ExecutionRequirementCode listName="einvoicing">required</cbc:ExecutionRequirementCode>
</cac:ContractExecutionRequirement>

[YvesJo]

Hi,

Information in JSON
Let’s have a look at what is defined in JSON.
We have the following fields that are not repeatable:

• BT-743-Lot with the relative XPATH "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='einvoicing']"
• BT-736-Lot with the relative XPATH "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='reserved-execution']"

Uniqueness
In the context of the parent node (ND-LotTenderingTerms), the field is not repeatable, and we may not find more than one:

• "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='einvoicing']"
• "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='reserved-execution']"

The uniqueness constraint applies to the whole relative path and not to its individual components. Here nothing indicates that cac:ContractExecutionRequirement should be unique.

One or more “cac:ContractExecutionRequirement”?
According to the schema, “cac:ContractExecutionRequirement” may only contain one “cbc:ExecutionRequirementCode”, therefore if BT-736-Lot and BT-743-Lot should coexist, they should be in different “cac:ContractExecutionRequirement” elements. This aggregate element is, from a schema perspective, repeatable.

Two ways to approach this

A repeatable Display Group
This is the approach proposed with the definition of a repeatable node:

• Define a repeatable Node associated to “cac:ContractExecutionRequirement”
• Define a Display Group associated to that node
• Add the different fields (BT-736-Lot, BT-743-Lot) in the Group
• Define a first set of rules to prevent the coexistence of the different fields under a same occurrence (i.e. so that BT-736-Lot and BT-743-Lot would occur under the same “cac:ContractExecutionRequirement” element)
• Define a second set of rules to prevent the existence of multiple Display Groups with a same information (e.g. to prevent that BT-736-Lot occurs more than once for a given Lot)

Multiple fields (without Groups)
This is how this has been implemented.

Conclusion
From the 2 approaches, the first one is way too complex and not user-friendly, as:

• All options will be displayed inside the group,
• The first set of rules should be applied as soon as the user specifies a value for any of the fields of the group (BT-736-Lot, BT-743-Lot …)
• The second set of rules should be applied as soon as the user requests for an additional occurrence of that group to prevent that additional groups contains information already defined in former occurrences of the group.

The second option is easier:

• fields are displayed only once on the UI,
• there is also no risk of have a same field twice,
• once a field is filled, the XML to be generated is immediate, independently from the other similar fields (just need to create the whole thing for "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='abc']", i.e. cac:ContractExecutionRequirement<cbc:ExecutionRequirementCode listName="abc">…</cbc:ExecutionRequirementCode></cac:ContractExecutionRequirement>)

Where does the xpath expressions with the predicates come from?

There is not more information in "cac:ContractExecutionRequirement[cbc:ExecutionRequirementCode/@listname='einvoicing']/cbc:ExecutionRequirementCode[@listname='einvoicing']" than in "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='einvoicing']"

If we want to split the relative path without losing information, then we need report a predicate at the level of the parent element “cac:ContractExecutionRequirement”

The same should be applied to "cac:ContractExecutionRequirement/cbc:ExecutionRequirementCode[@listname='reserved-execution']" which would then be split in "cac:ContractExecutionRequirement[cbc:ExecutionRequirementCode/@listname='reserved-execution']" and "cbc:ExecutionRequirementCode[@listname='reserved-execution']"

From the XSD, it is clear that the fields may not be under a same “cac:ContractExecutionRequirement” element and that therefore "cac:ContractExecutionRequirement[cbc:ExecutionRequirementCode/@listname='einvoicing']" and "cac:ContractExecutionRequirement[cbc:ExecutionRequirementCode/@listname='reserved-execution']" should be 2 different occurrences of a same element “cac:ContractExecutionRequirement” and shouldn’t then be defined as a single node.

I hope this will help clarify the situation

[sbo2718]

Given your explanation i would like to point out two things:

1. The eforms-editor-demo doesn't worklike you described, it also wraps the ExecutionRequirementCode elements into a single ContractExecutionRequirementCode. Here is the snippet:

      <cac:ContractExecutionRequirement>
        <cbc:ExecutionRequirementCode listName="reserved-execution">no</cbc:ExecutionRequirementCode>
        <cbc:ExecutionRequirementCode listName="einvoicing">allowed</cbc:ExecutionRequirementCode>
        <cbc:ExecutionRequirementCode listName="ecatalog-submission"/>
        <cbc:ExecutionRequirementCode listName="esignature-submission"/>
     </cac:ContractExecutionRequirement>

2. There are some BTs that try to create an attribute inside an element, e.g.
   BT-02-notice: "cbc:NoticeTypeCode"
   BT-03-notice: "cbc:NoticeTypeCode/@listname"

Applying your logic of always creating the entire relative xpath without checking if parts of the xml structure already exist, I would end up with two NoticeTypeCode elements - which is not compliant with the xsd.

[rouschr]

Please always provide the used SDK version.

[rengit62]

Very interesting discussion !
If one applies the predicate to the entire path ( xpathRelative ) of course the fields BT-736/743/744/764-Lot are unique
That is, during xml creation if a field is not repeatable, an initial xpath search has to be done.
In #405 I thought this approach was discouraged, perhaps I did not understand well.
Thanks a lot ! ( I am using sdk 1.7)
Renato

[rouschr]

In 405 I said "Maybe there are cases for which this behavior is desired."
In general for nodes and fields I think 1.8 will solve various problems, so it would be best to see what problems remain once 1.8 is in use.