XpathRelative/XpathAbsolute misunderstanding structure

[user6330]

what's the difference beetween the structure

identifierFieldID = "BT-137-Lot"
/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID

and

identifierFieldID = "BT-1375-Procedure"
/*/cac:TenderingTerms/cac:LotDistribution/cac:LotsGroup/cac:ProcurementProjectLotReference/cbc:ID[@schemeName='Lot']

in particular why in the first case
cac:ProcurementProjectLot explicit BEFORE that one of the child must have the attribute "scheme-name" while the second case cbc:ID has schemeName DIRECTLY?

I create my XML using logic on the direct presence of a schemeName (2 case).
How can I intercept the case 1?

[jaggaer-fgeniola]

Hi,
even for me the structure is still unclear (in general there are several inconsistencies) but the first case serves to identify which "cac:ProcurementProjectLot" section to connect the children to (since there may be several, with the same name but with of the different child ID attribute eg "Lot" and "LotsGroup").
Certainly for the "ID" field it is redundant but it is probably maintained for "consistency" with the other fields.
Case 2 is probably the one if you are not in case 1.
Instead, I found a problem when a field other than ID has to be created as the first element but which has in its absolute path the constraint of the value of the ID field attribute, it's a nonsense!
Regards

[rouschr]

We agree that the situation regarding attributes and xpath predicate for xml generation is difficult.
We gradually added new keys and new fields and nodes in the fields.json to help with this as this is highly requested.
SDK 1.7 has keys like "schemeName" in fields.json but only for some identifiers (if I remember correctly).
SDK 1.9 will introduce new attribute fields and attributeOf, attributeName and attributes to help with XML generation and form creation. For the time being in some cases you can get the schemeName from the xpath and for schemeName sometimes from schemeName in fields.json:

    "id" : "BT-137-Lot",
    "parentNodeId" : "ND-Lot",
    "name" : "Purpose Lot Identifier",
    "btId" : "BT-137",
    "xpathAbsolute" : "/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID",
    "xpathRelative" : "cbc:ID",
    "xsdSequenceOrder" : [ { "cbc:ID" : 2 } ], <------ 1.8
    "type" : "id",
    "attributes" : [ "BT-137-Lot-Scheme" ], <------ Will exist in SDK 1.9
    "idScheme" : "LOT", <-------------------------- Exists in SDK 1.7, helps with building the ids, pattern is "^LOT-\\d{4}$"
    "schemeName" : "Lot", <---------------------- Exists in SDK 1.7, should help with your case

    "id" : "BT-137-Lot-Scheme", <--------------- New "attribute field" in 1.9, attribute of "BT-137-Lot"
    "parentNodeId" : "ND-Lot",
    "name" : "Purpose Lot Identifier Schemename",
    "btId" : "BT-137",
    "xpathAbsolute" : "/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID/@schemeName",
    "xpathRelative" : "cbc:ID/@schemeName",
    "xsdSequenceOrder" : [ { "cbc:ID" : 2 } ], <------ 1.8
    "type" : "text",
    "attributeName" : "schemeName", <------ 1.9
    "attributeOf" : "BT-137-Lot", <-------- 1.9
    "presetValue" : "Lot"

https://github.com/OP-TED/eForms-SDK/blob/1.7.0/fields/fields.json
If you cannot find "schemeName", you can still use the xpath.

/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID

For now if you want to be safe with all cases you will have to parse the predicate in the last element and in the parent, see if you can find cbc:ID/ in the parent, then look at the /@schemeName='Lot' part and you can conclude that cbc:ID must have schemeName Lot.
This is not an impossible task, but some predicates may be harder to parse, this is why we decided to provide schemeName and later also the attribute information.