RE: [ubl] Questions regarding customization and context

["Sylvia Webb" <swebb@gefeg.com>]

Hello Martin,

 

Thank you very much for the comprehensive comments. They are very timely for our upcoming F2F meeting in Manhattan. If there are specific times during that week when you could join us by telephone, please let Jon know off-line and possibly we could include you by phone in the discussion about customization.

 

When the UBL 1.0 customization document was written it was deliberately generic. At that time, we did not have enough implementation experience to be able to draw specific recommendations for detailed customization guidance. That has changed and there are several topics that need to be included in a future version of the customization guidelines.

 

I will add your comments about the loosely defined definitions to our Issue list.  You also raise some important comments about cardinality that should be discussed by the TC as well.

 

Your questions regarding namespaces are better answered by other NDR experts.

 

WRT your questions regarding the number of documents that you have to refer to for UBL, imo, these are more applicable to implementation rather than developing the standards themselves.  I will email you off-line about this subject. I am working with other industry groups who are dealing with these same questions.

 

Can you please provide the TC with more information about your negative experiences with using restrictions combined with extensions? I think this would be helpful during the customization discussions.

 

Regards,

Sylvia

---

From: Martin Forsberg [mailto:martin.forsberg@amnis.se]
Sent: Wednesday, January 11, 2006 5:30 AM
To: ubl@lists.oasis-open.org
Subject: [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)

Sweden