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] | [List Home]


Subject: Re: UBL / e-procurement-review


As you are aware, the UBL Library Content team is now working to 
finalise its data models for release to your review team.  The diagrams 
you refer to were draft and have since been modifed, so the ones you 
will receive as UBL 0p80 will be different.  However, I though it might 
be useful to fill you in on the use of 'packages' within our UML model.

These logical groupings are entirely documentary in  nature.  that is, 
they are not manifested in the document schemas produced by UBL.  They 
are provided to aid analysts looking at the library by providing  a high 
level view.  this is similar to your (a) to (f) views.  We are not bound 
to these, nor do they provide any barriers to integration into the whole 
model.  They are lines around a group of objects.  The idea of using 
packages emerged from the use of diagrammatic notations (such as UML) to 
describe our model.  We did use these in an earlier version but this was 
not followed through in the last release (0p70).  We find them useful to 
focus smaller areas of the diagram into a scale that they fit onto A4 
pages and can be easily comprehended by the reader.  

We welcome your comments as to their value in your analysis.

Tim Benson wrote:

>One of the first tasks of the UBL e-Gov review may be to develop the
>consensus about the Packages used in UBL.  Packages specify the natural
>internal boundaries that allow us to break down the task into meaningful
>chunks.  Given consensus about these boundaries, we will be able to move
>forward quite quickly.  Time spent on this early on, to clarify assumptions
>about these boundaries, is likely to save time later on.
>
>On Friday Tim McGrath (TM) sent out the latest UBL model including separate
>diagrams for the following packages (in alphabetical order):
>
>1. Hazardous Item
>2. Item
>3. Party
>4. Payment (this actually contains the Party diagram)
>5. Procurement
>
>In addition the conceptual model has 3 additional packages (not named) which
>cover:
>6. Address of party
>7. Delivery and shipping
>8. Taxation
>
>Before making any further comments and suggestions, I would be very
>interested to understand the history of the UBL packages.  Were they there
>at the beginning, or have they been added at a relatively late date?  How
>important is it for the UBL community that the existing package boundaries
>be kept unchanged as corner stones of the whole project, or are they simply
>there for convenience?  How much debate has gone into the specification of
>the package boundaries?  What practical consequences would follow from
>moving a class from one package into another, or merging two packages?
>
>Our own work for OGC in UK  (the OGC model) also uses a similar number of
>packages with broadly similar composition, in this case:
>Six packages are generic -
>(a) Data types - this contains all of the data types used in the model (at
>the level of format and string length)
>(b) Document - contains general information about each document, including
>document identification and meta-data
>(c) Financial - contains financial information, including document prices,
>charges, discounts, taxation and rates of exchange, applicable at both
>document and line levels
>(d) Item - contains information about goods or services procured
>(e) Line - contains the structure of each line on a document
>(f) Party - contains information about each party (person or organisation).
>
>The next 2 packages relate to different contexts (flavours) -
>(g) Tutti-Frutti (all fruits) - contains messages that meet the more complex
>general requirements to meet best buying practice for the public sector,
>including international transactions
>(h) Vanilla - the simplest messages that meet the requirements for automated
>processing of most straightforward transactions.
>
>There is no right or wrong way to package up any model, but there are some
>well established principles such as:
>
>- Decomposition into packages which can be pursued separately
>- Composability so that the packages can be used independently
>- Understandability so that a human reader can understand each package
>without reference to others
>- Continuity so a change in one package only affects that package
>- The number of links between packages should be as small as possible.
>
>These principles could provide some criteria for looking at the packages,
>preferably one at a time.  I would suggest starting with Party and Item.
>
>
>  
>

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






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