Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces
Martin Matula <[email protected]>
| Newsgroups | gmane.comp.java.netbeans.modules.mdr.devel |
|---|---|
| Message-ID | <[email protected]> |
The reason for that is that I don't want to pollute the XMI with things that are not used by others. If some of the MDR users want to use the XMIWriter/Reader in a specific way, it is possible, but for the regular users of XMI it may be confusing to see these strange extensions in the XMI file. I think that including the type name in href/xmi.id is the right way to go in this case - it does not influence other usages of XMIWriter/Reader and works for fine for you. Martin Ronald Krijgsheld wrote: > Martin, > > Yep, you are right. passing the type is only useful if is the the specific > type. > We can encode this type information in the href. But, is there any reason > for not writing the specific type? > > Ronald > > ----- Original Message ----- > From: "Martin Matula" <[email protected]> > To: <[email protected]> > Sent: Thursday, July 25, 2002 5:09 PM > Subject: Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces > > > >>Hi Ronald, >>please note that the exact type of the element that the href in your >>example below points to is Model.PrimitiveType not Model.Classifier >>(which is just supertype of that). >>I thought that what Michiel was suggesting was to make XMIWriter to add >>information about the exact (most specific) object type (in this case >>Model.PrimitiveType) to the writen XMI and then send it to HRefResolver >>during the reading (see below). >> >> >>- for reading we would like to have the xmi writer to write the most >> >>specific type to the output file, because in that case the reader >> >>knows the actual type for which a placeholder needs to be created. >> >>Have I misunderstood something?? >>Martin >> >>Krijgsheld, Ronald wrote: >> >>>Martin, >>> >>>Take the following XMI line as example: >>> >>> <Model:Classifier >>> >> > href="http://www.omg.org/models/MOF1.4/XMI1.1/Model1.4/PrimitiveTypes.xml#St > >>>ring"/> >>> >>>In this case you can provide the HRefResolver with both: >>> - the type: Model:Classifier >>> - and the href. >>> >>>isn't it? >>> >>>Ronald. >>> >>>-----Original Message----- >>>From: Martin Matula [mailto:[email protected]] >>>Sent: Thursday, July 25, 2002 4:28 PM >>>To: [email protected] >>>Subject: Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces >>> >>> >>>Hi Michiel, >>> >>>Vries, Michiel de wrote: >>> >>> >>>>The issues which we see are the following: >>>> >>>>- the HRefResolver needs to receive a little bit more information: we >>> > need > >>>>to have the type of the object to be resolved. This to be able to create >>> > a > >>>>placeholder for the object. >>> >>> >>>How is the XMIReader supposed to find out the type? I guess this would >>>only work with the files written with our XMIWriter (that would add a >>>specific decoration to each href). But in that case, why don't you >>>implement the XMIReferenceProvider the way that it will encode the type >>>information in the returned reference (xmi.id and href)? This is a good >>>solution for you and does not require any changes to be made to XMI >>>writer used also by the people that do not need this. >>> >>> >>> >>>>- for reading we would like to have the xmi writer to write the most >>>>specific type to the output file, because in that case the reader knows >>> >>>the >>> >>> >>>>actual type for which a placeholder needs to be created. >>> >>> >>>Why don't you encode the type information in xmi.id/href? (see above) >>> >>> >>> >>>>- for writing we need to have a link to the refObject and a String >>>>representing the current filename. In that way you can distinguish if >>> > the > >>>>refObject needs to be in a different filename than the current one. >>> >>> >>>OK, I thought that this may be passed to the XMIReferenceProvider >>>constructor, however I can add it as a parameter to getReference method >>>if you want. >>>Martin >>> >>> >>>--------------------------------------------------------------------- >>>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]