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: A practical question on Core components storage, UBL, OAG, etc


Hello all,

We are in the process of defining a storage model for an Australian
repository of standards.  The CCTS v1.9 provides a very detailed model
but:
1	It does not map directly to ebXML RIM (I know that there is a
project underway to do this).
2	It would be very time consuming to populate a regsitry to the
level of detail defined in CCTS1.9 without some tools to transform UML
model <-> XSD schema <-> Registry Meta-data.
3	It is difficult to accommodate existing standard libraries like
OAG 8.0 that does not align with CCTS (I know that OAG 8.1 beta presents
an initial alignment but it is not yet in common use..).
4	CCTS1.9 provided a currently approved list of core components
types but not yet any definitions of basic core components or aggregate
core components.

So we have decided, for the time being, to simplify the storage model.
Some immediate practical questions are:
1	Should we store both the UBL <Address> and OAG
<PostalAddressBase> as aggregate core components - they are both context
neutral re-usable components and so are candidates to become standard
aggregate core components.  The problam is that they are different in
both syntax and semantics.  Is it better accept duplication and make
them both core components - or to pick one as our reference "address
core components" and make the other an ABIE with a context of "legacy
standard compatibility"?  
2	If, for example, we pick UBL as our reference core component
then we need to be able to map the OAGIS address block back to the UBL
address block via a context driver.  The problem is that OAG uses a
repeating <addressLine> element whilst UBL explicitly defines <Street>,
<HouseNumber>, etc - so there is no match at BCC <-> BCC level.  The way
to make a match is to add a new element to UBL which is a repeating
<AddressLine> - but then there would be duplication within the UBL
address reusable component.  Is it a REQUIREMENT of the CCTS that BBIE
elements must map to a corresponding BCC element?

My gut feeling is that if we don't start to build a library of
non-duplicated reference core components then there is little point
building a library at all - we may as well just publish the separate
libraries as they are today.  This implies to me that we will probably
only be able to go down to the resolution of reusable component like
<Address> in terms of relating standards like HL7, EANCOM, etc back to
the reference core component library.

Any gems of wisdom, comments, answers, etc on this issue will be
appreciated.

Regards,

Steve Capell
RedWahoo
Sydney, Australia
Tel : +61 410 437854



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