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.
>>>
>>>
>>
>>
