xpathRelative: "@listName"

[karel-debrabandere-bosa-fgov-be]

Hi,

In the fields.json file there are some fields that have "xpathRelative" : "@listName". Note that these fields also have the same @listName as the last part of their xpathAbsolute.

I cannot find any documentation on this. What is this supposed to imply?

[YvesJo]

Hi Karel,
Nodes (ND-xxx) help define display groups and a same XML complex element may be used in different contexts for different purposes; to differentiate the contexts, it may be necessary to add predicates which may rely on some information inside the group itself.
The whole path is built from the context by adding the relative path which then may lead to duplicate information as you highlighted.
I hope this answers your question.

[karel-debrabandere-bosa-fgov-be]

Hi Yves,

I understand that @listName is a valid xpath expression that references an attribute.

What is confusing to me is the following:

Almost all fields as defined in fields.json that have "type" : "code" have a xpathRelative that explicitly references xml nodes:

• "xpathRelative" : "cac:Country/cbc:IdentificationCode",
• "xpathRelative" : "cac:PostalAddress/cbc:CountrySubentityCode",
• ...

As part of our form-to-xml conversion, we use these xpaths to build the xml document. The last node implied by the xpath expression will be the leaf node in the xml document that gets the selected value as content and the codelist id as listName attribute:

• ... <cac:Country><cbc:IdentificationCode listName="country">some-country</cbc:IdentificationCode></cac:Country> ...
• ... <cac:PostalAddress><cbc:CountrySubentityCode listName="nuts">some-value</cbc:CountrySubentityCode></cac:PostalAddress> ...

Out of 250 fields of "type" : "code", only 7 do NOT follow this structure:

• 1 has "xpathRelative" : "cbc:NoticeTypeCode/@listName",
• 3 have "xpathRelative" : "cbc:ItemClassificationCode/@listName"
• 3 have "xpathRelative" : "@listName",

Why do these code fields suddenly use @listname references in their xpaths, while vast majority of fields don't reference this attribute explicitly?

• The fields with "xpathRelative" : "cbc:NoticeTypeCode/@listName", and "xpathRelative" : "cbc:ItemClassificationCode/@listName", we could interpret as "xpathRelative" : "cbc:NoticeTypeCode", and "xpathRelative" : "cbc:ItemClassificationCode" instead, and then treat them the same way as all the other codelist fields.
• BUT for the last example ("xpathRelative" : "@listName") we cannot use this 'fix'. Instead we will need to add additional logic to deal with this rare exception.

I would have expected all fields of "type" : "code" to be structured similarly and not have these 7 exceptions.

[YvesJo]

Hi Karel,
The 7 fields correspond to Business Terms (BT-03, BT-26) that support, or may support in a near future, different values, and the fields had to be explicitly identified as they follow a different logic.

[karel-debrabandere-bosa-fgov-be]

so are you saying that these BTs could map to the same xml node and could, depending on the context, cause that node to have different value types and attributes?

I would expect to see different value types reflect into different xml nodes instead.

[YvesJo]

A same BT may indeed be associated to multiple fields, a typical example is for information that may apply to the Procedure as a whole, a lot, a part or a group of lots.
The acceptable values for a given field may vary depending on the context, should the field point to an attribute or to an element. For a given field, the used attribute will not change, just its value may vary and it is the same for the elements (element name will not change just its content). Also there is no dual behavior where a field type would vary depending on the context.
I hope this answers your concern.