[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:email@example.com title:Senior Consultant fn:Joseph M. Chiusano end:vcard