OPT-090-Lot

[rengit62]

Hi Lab
that field is type code
"id" : "OPT-090-Lot",
"parentNodeId" : "ND-FABuyerCategories",
"name" : "Buyer Categories",
"btId" : "OPT-090",
"xpathAbsolute" : "/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingProcess/cac:FrameworkAgreement/cac:SubsequentProcessTenderRequirement[cbc:Name/text()='buyer-categories']/cbc:Name",
"xpathRelative" : "cbc:Name",
"type" : "code"

but in xsd :
<xsd:complexType name="TenderRequirementType"> <xsd:sequence> <xsd:element ref="ext:UBLExtensions" minOccurs="0" maxOccurs="1"/> <xsd:element ref="cbc:Name" minOccurs="1" maxOccurs="unbounded"/> <xsd:element ref="cbc:Description" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="cac:TemplateDocumentReference" minOccurs="0" maxOccurs="1"/> </xsd:sequence> </xsd:complexType>

cbc:Name is udt:NameType

Bye
Renato

[YvesJo]

There are multiple fields for which the type defined differs from the element type as defined in the XSD. Most of the time it is due to the fact that there is only an exhaustive list of possible values for which a codelist has been defined on purpose. When the element is not of code type, then no listName attribute may be associated. (e.g. BT-01).

[rengit62]

Yves,
perhaps I did not understand.
Is there a reason why do not remove "type" : "code" from the field definition ?
To avoid listName association to a field defined to have it, as you wrote, the unique way is setting a very ugly "IF" in the program.
Bye
Renato

[YvesJo]

You understood well, and an alternate way should also be identified. Unfortunately, this couldn't be addressed yet. I will raise that concern.