[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Questions regarding customization and context
Hello UBL
TC,
Perhaps this issue has already been
discussed and solved in this list. If
so, please help me find the documents or related messages. We are discussing
different complications and strategies regarding development of
subsets/customizations of UBL 2.0. As today, UBL 2.0 consists of approximately
29 business documents, the majority used in the procurement process. All shared
components (BIEs) are placed in the common library, the transportation library
or the procurement library. Due to the great number of business documents and
the more comprehensive model (compared to UBL 1.0) the reusable components tend
to be very complex and loosely defined. In the Invoice, for example, there is a
1 to many AccountingDocumentReference, and in this class there is (among others)
a 1 to many InvoiceDocumentReference. As you can see, this situation makes it
possible to reference more than one invoice in more than one way. (Repeat AccountingDocumentReference with
just one InvoiceDocumentReference in each, or use one
AccountingDocumentReference and repeat
InvoiceDocumentReference).
In our customization we might like to
restrict this and set the InvoiceDocumentReference to 1..1 and
AccountingDocumentReference 0..n.
This requirement can come from the
context (like industry or geopolitical target market) but it can also be a
requirement that is used in one business document, but is contradicted in
another used in the same scenario (maybe the CreditNote uses
AccountingDocumentReference in another way).
So finally to my
questions
-
How do we make the context
visible in the schema and xml instance? Can we change the namespace of the
business document to reflect the context, or does that violate some
UBL-policy?
- If the reusable components can’t be reused between different business document that are used in the same process and in the same context, how should we resolve this? It would require change of namespace to the reusable schemas. The alternative is to deploy different schemas with contradicting components with the same namespaces.
- Which method should we use to develop the customization? I have had some bad experiences using restrictions (especially in combination with extension).
It is very important that the schemas are easy to understand. If we have to refer to several documentations (like schema, instance samples, and other documents) to define what is part of a specific business document in a specific context, I think we will have a problem.
In the EAN.UCC (GS1) NDR the recommendation is to reflect the context in namespaces. What I've heard, un/cefact has not decided on the subject. It would of course be of great value if the strategies were aligned.
Thanks for your time,
Martin Forsberg
SFTI (Single Face To Industry)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]