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?


Here are some specific references:

"
7.3.1    Class ObjectRef
An instance of the ObjectRef class is used to reference a 
RegistryObject. A RegistryObject may be referenced via an ObjectRef 
instance regardless of its location or that of the object referring to it.

7.3.1.3    Attribute home
Every ObjectRef instance may optionally have a home attribute specified. 
The home attribute if present must contain the base URI to the home 
registry for the referenced RegistryObject. The base URI to a registry 
is described by the REST interface as defined in [ebRS].
 
7.3.1.4    Local Vs. Remote ObjectRefs
When the home attribute is specified, and matches the base URI of a 
remote registry, then ObjectRef is referred to as a remote ObjectRef.
If the home attribute is null then its default value is the base URI to 
the current registry. When the home attribute is null or matches the 
base URI of the current registry, then the ObjectRef is referred to as a 
local ObjectRef.


"

Chiusano Joseph wrote:

>Farrukh, I defer to you on this one.
>
>Duane Nickull wrote:
>  
>
>>I had read this but thought it refers to the Registry Home, not a
>>Registry Object Home.
>>
>>Clarification?
>>
>>Duane
>>
>>Chiusano Joseph wrote:
>>    
>>
>>>I believe so - ebRS v2.35, line 5116 (p.149):
>>>
>>><Quote>
>>>The following rules govern how a registry joins a federation:
>>>
>>> Each registry must have exactly one Registry instance within that
>>>registry for which it is a home. The Registry instance is owned by the
>>>RegistryOperator and may be placed in the registry using any operator
>>>specific means. The Registry instance must never change its home
>>>registry.
>>></Quote>
>>>
>>>Joe
>>>
>>>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.
>>>>
>>>>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/
>>>>        
>>>>
>>--
>>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>




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