[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [TN Proposal] Mapping Business Information Models toebXML RegistryInformation Model (Was: [regrep] UN/CEFACT-ICG adopts freebXMLRegistry)
Duane, Actually the CAM template allows you to in-line semantics into the template content reference section, or sub-assembly includes if you wish to make the thing work off-line, as well as with a regisry. But - I think this is a deployment choice. Basically you can design and build around the registry - and then have your modelling tool output the CAM templates in one of two modes - with embedded referencing - if no registry is to be used - or with referential links to registry if not. We - from the Registry standpoint - just need to cover off the registry function set. As I noted before - separating these roles out into layers makes solving this much easier. Thanks, DW Duane Nickull wrote: > It is not my model. It is the approved CCTS and UMM models. > While jCam may do that, it requires certain details be available (the > artifacts themselves) and that the designers can access certain > information ourside of a registry environment. As per UN/CEFACT's > goals of electronic and non electronic business functionality, use of > a registry is not always a pre-required component. > > CAM does solve many of the problems, but ONLY if the information is > present in the schema fragments it consumes. > > Duane > > David RR Webber wrote: > >> Duane, >> >> I do not buy your model here. >> >> When you use jCAM and the noun definitions we are developing for SCM >> - you head all these problems off at the pass. >> >> This was the lesson we learned from the CEFACT work - that you need >> to separate the assembly mechanism from >> the noun representations. We did that and moved on. >> >> The context is then managed and exposed by the CAM templates >> themselves - and since they are simply XML instances >> you can query across them by UID ( *not* UUID) and garner the >> associations and usage easily. >> >> And the noun definitions as defined are covering off the gaps that >> the RIM and UMM models of CC are not accounting >> for. Again - no giant surprise here - thats exactly what we deisnged >> them for an have foreseen - the difference between >> the model layer and the implementation layer. >> >> Next up we will be working with the CEFACT folks on implementing this >> in registry - so they should be able - as >> noted in the CEFACT meeting - be able to take the existing ISO >> dictionary work - use the noun definition format - and >> store those semantics into registry. >> >> The jCAM engine can then read and apply those from the registry >> during either validation of assembly of content or both. >> >> Thanks, DW >> ========================================================================== >> >> >> Duane Nickull wrote: >> >>> >>> >>> Farrukh Najmi wrote: >>> >>>> A few special cases in CCTS mapping do not obviate the need for a >>>> generic mapping TN that covers most domain specific mapping and >>>> 90%+ of CCTS. >>>> What is the downside of doing a generic mapping document as you see >>>> it? >>>> >>> The downside is that there are dependencies on the storage for what >>> must be serialized on the wire. If that information is not stored >>> as per the generic mapping, then the whole mechanism may not work. >>> Each artifact has different requirements for what must be serialized >>> on the wire. BIE's need to know what CC they came from, they also >>> need to know the contexts (UUID for a set of contexts) that lead to >>> their existence, CC's do not need to know the BIE's spawned from >>> them, yet do need to know there are BIE's and provide a mechanism >>> (Classification tree?) for others to locate the BIE for a specific >>> set of contexts. >>> >>> The set of contexts is also another huge problem. There may be 8-10 >>> million. One BIE may be used for a range of contexts (example - all >>> french speaking countries and regions). Just creating that many >>> classifications will crash most registry implementations I know of >>> or make them unmanageably slow. >>> >>> These are just a few of the potential problems. >>> >>> Duane >>> >>> To unsubscribe from this mailing list (and be removed from the >>> roster of the OASIS TC), go to >>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. >>> >>> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]