Re: [ubl] Re: Restracturing UBL spreadsheet V1.0 to V1.1

[Tim McGrath <tmcgrath@portcomm.com.au>]

i agree "specialized" is ugly.  my only  reason for its use is that it 
parallels the core component type terminology we already have.  It made 
me realize how our hierarchy of models relates to core component types - 
we are just working at a higher level of granularity.

I guess with the adoption of the ATG2 core component type schemas we 
lose the terms "specialized/unspecialized" anyway.  Dont worry, I wont 
argue for "qualified /unqualified"   ;-)

We talk about the difference between "common" and "core" at the last 
plenary.  We felt "common" meant it was used in all cases (which these 
things may not be). Perhaps we were too pendantic.

My dictionary says:
common = often occurring or frequently seen
core = the central or most important part of something

With this interpretation ("often" not "always") I can live with Jon's 
suggestions.


jon.bosak@sun.com wrote:

>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.
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
(coming soon from MIT Press)
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476