Thank you, Kees, for the providing your detailed perspective.
Just to have the clarifications and counterpoints in the same thread:
- The Catalogue is a business document in its own right. It is not necessarily a response to a Catalogue Request, neither in UBL nor in real-world practice. A Catalogue may be distributed independently as a standing offer, and constraining the cardinalities of the elements in the document based on the possibility that it might at times be a response to another document should be defined at Profile level and not in the document schema itself.
- Saying that "this Catalogue applies to, e.g., the Benelux region" is semantically different than saying "this Item applies to the Benelux region". One defines the commercial scope of the Catalogue as a whole, while the line-level one defines restrictions or variations for individual items. These are complementary, not redundant, and both represent real business cases.
- The requirement to be able to express the geographical scope of the Catalogue at document level is a common business requirement and is being brought to us by a community of users. We've always worked from the idea that UBL should be "designed to plug directly into existing business practices", not the other way around. And when a business practice requires the present of an element not yet existing in UBL, it's been our position to accommodate, not to ask industry to change their business practice to conform to UBL.
- Suggesting that a receiver of a Catalogue can simply infer the intended geographical scope of the document by aggregating the item level data and then "doing the math" is against UBL's core principle of manifest values. It's also not how UBL is modelled elsewhere (document level totals vs. line level amounts, just to give an example). "The onus is on the sender to include all information, such as all pertinent indications and all relevant sums or calculations. The receiver must not be required to make any assumptions nor perform any computations whatsoever when dealing with the sender's information.".
Additionally, I'm not sure that IND6 applies in this case. The rule that "the absence of a construct or data in a UBL instance shall not carry meaning" is meant to prevent inferred negation, e.g., omitting ProjectReference from an invoice does not imply "no project". Adding an optional ApplicableTerritoryAddress at document level neither violates nor relies on that rule but it simply allows the sender to state the scope explicitly when relevant.
Best regards,
Kenneth
Este correo electrónico y cualquier archivo transmitido con él son propiedad de Efact S.A.C., contiene información confidencial, y están destinados exclusivamente al uso de la persona o entidad a la que van dirigidas. Si usted no es el destinatario señalado, no puede difundir y distribuir o copiar este e-mail. Por favor notifique inmediatamente al remitente por correo electrónico si usted ha recibido este correo electrónico por error, y eliminar este correo electrónico de su sistema. Si usted no es el destinatario, se le notifica que revelar, copiar, distribuir o tomar cualquier acción basada en el contenido de esta información está estrictamente prohibida.
This email and any files transmitted with it are the properties of Efact S.A.C., contains confidential information, and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you may not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake, and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.