Re: writing collection of refobjects through xmiwriter

Hi Ronald,
I agree that it is not such a problem to implement this functionality, 
however the semantics of such a write method will be quite different 
from the semantics of write(collection) method because of the following 
reasons:
In the simple write(collection) method the collection determines which 
objects are writen to the XMI file. However in the more complicated 
write method collection is just used as a starting point for searching 
for objects. Now the problem is, how to enforce that 
XMIReferenceProvider returns href (not xmi.id) in case when XMIWriter is 
asking for href of object not contained in the collection that was sent 
as a parameter. If the XMIReferenceProvider would return xmi.id instead 
of href, XMIWriter would serialize that object (although it was neither 
in the original collection nor it is a component of any object in the 
original collection) and all the comonents of that object transitively, etc.
Do you think that this behavior is OK or would it be better to throw an 
exception from the XMIWriter if xmi.id is returned where href was expected?
Martin


Krijgsheld, Ronald wrote:
> Hi Daniel,
> 
> Martin proposes in point 1:
> 
>      Extend XMIWriter interface by adding the same write methods that it
>      already has but with additional parameter of type XMIReferenceProvider.
> 
> So, I expected a new method on the XMIWriter interface:
>      write(Collection refObj, XMIReferenceProvider provider)
> 
> Now, I understand this functionality is not intended to be implemented.
> 
> Is there any problem with providing this functionality? (I do not see much
> extra work
> for this).
> 
> Ronald
> 
> -----Original Message-----
> From: Daniel Prusa [mailto:[email protected]]
> Sent: Thursday, July 25, 2002 4:14 PM
> To: [email protected]
> Subject: Re: writing collection of refobjects through xmiwriter
> 
> 
> Hi Ronald,
> 
> my statement is still valid, write(collection) does not create any hrefs to
> objects that are not part of the collection parameter.
> 
> To serialize repository content in multiple files and control what is where
> written you can use the proposed write(OutputStream, RefPackage[],
> XMIReferenceProvider) method. If your XMIReferenceProvider returns xmi id
> for
> every RefObject that you want to write in a file and href for every
> RefObject
> that you do not want to write in the file, then you will achieve the desired
> behaviour (this writing method will preserve all links).
> 
> In another words, to serialize a MOF repository content in multiple files
> (let's
> say File_1, ..., File_N) means to call write(OutputStream, RefPackage[],
> XMIReferenceProvider) method N-times and on each i-th call provide a proper
> XMIReferenceProvider returning xmi id's for all RefObjects that you want to
> write in File_i.
> 
> Daniel
> 
> 
>>Hi Daniel,
>>
>>>>From the the proposal that Martin send to this list, I do not see why
> 
> this
> 
>>won't work for the write(Collection) method. Is your statement about this
>>still valid?
>>
>>We want to serialize a MOF repository in multiple files and want to
> 
> control
> 
>>what is written on RefObject basis.
>>
>>Ronald
>>
>>-----Original Message-----
>>From: Daniel Prusa [mailto:[email protected]]
>>Sent: Wednesday, July 24, 2002 8:30 AM
>>To: [email protected]
>>Subject: Re: writing collection of refobjects through xmiwriter
>>
>>If you split outermost objects in repository into several collections and
>>write
>>each collection to a different file using write(collection) method, then
> 
> you
> 
>>will loose links linking objects across the collections.
>>
>>We plan to add some support for writting in multiple files (not based on
>>write(collection) method). We send a proposal when it is ready.
>>
>>Daniel
>>
>>
>>>Does that mean, that when writing a repository, through the write
>>>(collection) method, I can never be sure that all links are written?
>>
> This
> 
>>>gets imported when we want to write a repository in multiple files.
>>>
>>>In our case, probably not that important because our associations always
>>>have references.
>>>
>>>Ronald
>>>
>>>-----Original Message-----
>>>From: Daniel Prusa [mailto:[email protected]]
>>>Sent: Tuesday, July 23, 2002 11:01 AM
>>>To: [email protected]
>>>Subject: Re: writing collection of refobjects through xmiwriter
>>>
>>>
>>>>How is it written exactly? A link can be in different namespace as the
>>>>objects they link?
>>>>
>>>>If I want to serialize all RefObjects within a namespace, I will also
>>>
>>get
>>
>>>>the links between those RefObjects, while these links can be defined
>>>
> in
> 
>>a
>>
>>>>different namespace.
>>>
>>>Yes, if there are RefObjects that are instances of class C and links
>>
>>linking
>>
>>>these objects, where the association related to these links is A, then A
>>
>>can
>>
>>>be
>>>possibly defined in a different package than C. (I hope I have
>>
> interpreted
> 
>>>your
>>>description correctly ...)
>>>
>>>Daniel
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [email protected]
>>>For additional commands, e-mail: [email protected]
>>>
>>>--
>>>The contents of this e-mail are intended for the named addressee only.
>>
> It
> 
>>>contains information that may be confidential. Unless you are the named
>>>addressee or an authorized designee, you may not copy or use it, or
>>
>>disclose
>>
>>>it to anyone else. If you received it in error please notify us
>>
>>immediately
>>
>>>and then destroy it.
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [email protected]
>>>For additional commands, e-mail: [email protected]
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [email protected]
>>For additional commands, e-mail: [email protected]
>>
>>--
>>The contents of this e-mail are intended for the named addressee only. It
>>contains information that may be confidential. Unless you are the named
>>addressee or an authorized designee, you may not copy or use it, or
> 
> disclose
> 
>>it to anyone else. If you received it in error please notify us
> 
> immediately
> 
>>and then destroy it.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [email protected]
>>For additional commands, e-mail: [email protected]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
>