Re: writing collection of refobjects through xmiwriter

Martin,

I like the starting point approach. This way it is possible to fine tune
what needs to be written in the XMIReferenceProvider.

With this view the old write(Collection) method can be implemented with a
default XMIReferenceProvider that just returns xmi.id for elements in the
collection and hrefs otherwise.

Ronald

----- Original Message -----
From: "Martin Matula" <[email protected]>
To: "Krijgsheld, Ronald" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, July 25, 2002 4:41 PM
Subject: 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]
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>