RE: writing collection of refobjects through xmiwriter

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]


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