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