OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ubl-lcsc] Domain Namespaces


(This is a communiqué from the NDRSC to the LCSC.  I've been appointed to
communicate our consensus on these issues.)

There are a couple disparities between the NDR guidelines and the way the
0p70 schemas actually came together.  These became evident in this morning's
NDR meeting.  

I. Namespace per Domain -- not per Document

From lines 650-653 in version 21 of the NDR doc
(http://oasis-open.org/committees/ubl/ndrsc/release/wd-ublndrsc-ndrdoc-21.do
c):

	Two higher-level "domain" namespaces are defined, one for the
"ordering" domain and another for the "invoicing" 
	domain. The Order Domain namespace defines message types and ABIEs
specific to the ordering domain. Similarly, the 
	Invoice Domain namespace defines message types and ABIEs specific to
the invoicing domain.

We would therefore expect to see document types for Order, Order
Cancellation, Order Response, Order Response Simple all defined in a single
"Order Domain" namespace.  Unfortunately, that isn't the case in 0p70.  That
release assigns each document type to its own separate namespace.

The recommendation here is that in the next UBL release we merge those many
namespaces into one, "Order".


II. What "Domain" Should Receipt Advice and Despatch Advice be Part of

It's fairly clear where the ordering and invoicing document types should to,
but we don't know where to put Receipt Advice or Despatch Advice document
types.  Do we need another domain or two?

Please, LCSC, prescribe a domain/home for each of those document types.


III. The "Common Aggregate Types" Namespace is Bloated

The "Reusable" or "Common Aggregate Types" (cat) namespace was designed to
contain vocabulary _shared_ between the various domain namespaces.
Unfortunately, in the 0p70 release, the cat namespace contains many
vocabulary items that are _not_ shared between the various domains.  In fact
it contains the whole vocabulary sans the CCT's and the document types
themselves.

I was about to ask LCSC to perform an analysis to partition the vocabulary
elements but in thinking about it I realize that is the _wrong_ way to
approach this.  Instead I'd like to ask NDRSC (or Tools and Techniques) to
generate an analysis tool that will do this partitioning for us.  Once we
find homes for the document types (in the various domain namespaces) it
should be a small matter to identify the vocabulary elements that are shared
among two or more domains.  Those would go into the cat namespace.  For the
remainder, each would be "pushed up" into a domain namespace.


-Bill


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC