OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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/
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]