MHonArc v2.5.0b2 -->
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]