Duane Nickull wrote:
> One item that needs to be possibly added is a "home" localtion for
> each Registry Object. Each object could have an associated value of
> its' home location and a psuedo "refresh from home location" attribute
> to ensure that content is fresh, yet it is unnecessary to poll the
> home address looking for updates in a manner that uses resources
> unwisely.
>
> I don't know if the Registry team has looked at this as part of the
> federated approach.
We have Duane. There is an attribute called "home" in the ObjectRef
class in RIM. Every objects has a home attribute associated with it that
determines which registry is its home registry.
>
>
> Duane
>
>
> Chiusano Joseph wrote:
>
>> Thanks Duane - that's the exact kind of feedback I was looking for.
>>
>> Sounds like this is covered in v3.0 by the Federated Registries Object
>> Replication feature - from ebRS v2.35, lin 5188 (p.151):
>>
>> <Quote>
>> Any Submitting Organization can create a replica by using the standard
>> SubmitObjectsRequest. ...
>> Creating a local replica requires the destination registry to read the
>> state of the remote object from the source registry and then create a
>> local replica of the remote object. </Quote>
>>
>> Joe
>>
>> Duane Nickull wrote:
>>
>>> Joseph:
>>>
>>> Matt MacKenzie, David Webber and I implemented this stuff 2 years ago
>>> and out that each has merits. The problem you have identified is that
>>> once a CC or BIE is copied, serialized and transmitted to a remote
>>> location, it looses its' RIM metadata (context). That includes
>>> classifications, associations etc. Therefore, if CC's and BIE's
>>> are to
>>> be stored in a registry, users need to either copy the appropirate RIM
>>> data with it, or duplicate the RIM data in the Registry Objects itself
>>> (an un-elegant solution IMHO).
>>>
>>> IN the Wrox book 'Professonal ebXML Foundations" a chapter was written
>>> identifying this problem and a solution. I still believe the solution
>>> lies somewhere ins a hybrid approach. This could involve wrapping the
>>> actual Registry Object with a RIM Metadata envelope before it is
>>> serlialized and transmitted.
>>>
>>> Duane Nickull
>>>
>>> Chiusano Joseph wrote:
>>>
>>>> All,
>>>>
>>>> I've been thinking more about this issue...that is, given a set of
>>>> metadata attributes (such as those specified in the Core Components
>>>> spec), which should be part of the RIM (through a binding) and which
>>>> should be "pushed down" into the contents - i.e. as a "wrapper" for
>>>> the
>>>> core component or associated entity.
>>>>
>>>> For example, lets say we need to provide for the following metadata
>>>> for
>>>> a Core Component (this is all hypothetical):
>>>>
>>>> - Object Type (Basic Core Component (BCC), Basic Business Information
>>>> Entity (BBIE), etc.)
>>>> - Creation Date
>>>>
>>>> And let's say the Core Component contained "Contact Information"
>>>> for an
>>>> individual. In general, there are 2 approaches to representing this
>>>> metadata (let's say for simplicity that you cannot split the
>>>> metadata up
>>>> - that is, you must include all metadata in one approach):
>>>>
>>>> (1) As part of serialization
>>>> (2) As part of RIM
>>>>
>>>> Approach #1 would look as follows (note "CoreComponentMetadata"
>>>> header,
>>>> with data in "CoreComponentData" element):
>>>>
>>>> <CoreComponent>
>>>> <CoreComponentMetadata>
>>>> <ObjectType>BCC</ObjectType>
>>>> <CreationDate>2003-01-03</CreationDate>
>>>> </CoreComponentMetadata>
>>>> <CoreComponentData>
>>>> <ContactInformation>
>>>> <PersonFirstName>Harry</PersonFirstName>
>>>> ...more elements here...
>>>> </ContactInformation>
>>>> </CoreComponentData>
>>>> </CoreComponent>
>>>>
>>>> Approach #2 would look as follows:
>>>>
>>>> - ObjectType and CreationDate are RIM attributes
>>>> - Serialization looks as follows (note no "CoreComponentMetadata"
>>>> element):
>>>>
>>>> <CoreComponent>
>>>> <CoreComponentData>
>>>> <ContactInformation>
>>>> <PersonFirstName>Harry</PersonFirstName>
>>>> ...more elements here...
>>>> </ContactInformation>
>>>> </CoreComponentData>
>>>> </CoreComponent>
>>>>
>>>> My question is: What are the distinct advantages and disadvantages to
>>>> each of these approaches? And which previals (if any) as the most
>>>> advantageous/preferred approach to representing Core Components and
>>>> their associated entities?
>>>>
>>>> Looking forward to some great insight...Thanks!
>>>>
>>>> Joe
>>>
>>>
>>> --
>>> VP Strategic Relations,
>>> Technologies Evangelist
>>> XML Global Technologies
>>> ****************************
>>> ebXML software downloads - http://www.xmlglobal.com/prod/
>>
>>
>
>
--
Regards,
Farrukh
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
