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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: Restracturing UBL spreadsheet V1.0 to V1.1


I agree with Tim that we should avoid the word "core" to prevent
confusion.  But I also think that we should avoid "specialized"
and "unspecialized" (especially the latter, as negatives embedded
in terminology are both ugly and weak).  It seems to me that we
have four kinds of things here:

 - documents

 - document-specific elements

 - domain-specific elements

 - common elements

So I would suggest the following terminology:

 - Common Library (contains elements that are used in more than
   one domain)

 - Domain-specific libraries with names such as "Procurement
   Library," "Transportation Library," etc.

That is:

   Bosak                   McGrath                 Saito
   -----                   -------                 -----

   Common Library          Unspecialized           Core Library
                           Library

   Procurement             Specialized             Common Procurement
   Library                 Procurement             Library
                           Library

   Transportation          Specialized             Common
   Library                 Transportation          Transportation
                           Library                 Library

Jon

==================================================================

   Date: Sun, 26 Jun 2005 09:20:04 +0800
   From: Tim McGrath <tmcgrath@portcomm.com.au>
   CC: Michael Dill <dill@gefeg.com>, UBL TC <ubl@lists.oasis-open.org>

   One thing we need to accommodate in this idea is how it relates to the
   ebXML Core Component Technical Specification. I suspect this is behind
   Michael's question.

   I now realize that we may cause some confusion by calling them "Core
   BIEs". Because the ebXML Core Component Technical Specification also
   uses the word "core" but not in the same sense we mean.

   In ebXML it means "from which everything is derived". So all BIEs must
   be derived from a "core" component.

   I think we meant "core" as in "the central or most important part of
   something". So not all BIEs are derived from our "core" BIEs. It is just
   our "core" BIEs are used across all contexts.

   Whilst struggling for a better term I realized we have a precedent to
   follow. We could follow the principles used for Core Component Types
   libraries. But instead of Data Types being derived from Core Component
   Types, we have BIEs derived from Core Components.

   Core Component Types would be equivalent to the "core components" of UBL
   (which we will need to explicitly identify).
   Unspecialized (or Unqualified) Types would be equivalent to our "core" BIEs.
   Specialized (or Qualified) Types would be equivalent to the document and
   common-in-context BIEs.

   So I thought maybe instead of "core" BIEs , we could call them
   "unspecialized" BIEs and the common-in-context could be called
   "specialized".

   This means that we have:

   one "unspecialized" library of re-usable BIEs that are used in any
   document types (the same as Saito-san's "core BIEs").

   one "specialized procurement" library of re-usable procurement BIEs that
   are used in any procurement document types (the same as Saito-san's
   "common procurment BIEs"). At a schema level this could be called the
   Procurement Aggregate Components.

   one "specialized transportation" library of re-usable procurement BIEs
   that are used in any transportation document types (the same as
   Saito-san's "common transportation BIEs")

   Each document type definition would include the "unspecialized" library
   and also the "specialized" library for its context of use. The main
   reason for separating them into "unspecialized" and "specialized" is to
   make the library more manageable and useable for specific contexts.

   We have not activiely discussed this yet, but all of these should be
   derived from a library of UBL "core components". This Core Component
   library will not be used directly in any document models - just like the
   core component types aren't used in the documents either. Its purpose is
   to provide the building blocks and it contains only the information
   pieces necessary to describe a specific concept.



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