Re: [regrep] Core Components and XML Serialization - Which Approach?

[Duane Nickull <duane@xmlglobal.com>]

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.

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


-- 
VP Strategic Relations,
Technologies Evangelist
XML Global Technologies
****************************
ebXML software downloads - http://www.xmlglobal.com/prod/


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>