RE: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces

Hi Martin,

Thanks, we'll go for encoding the type in the href. 

About the other point:

Martin wrote:
> 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.
We can pass it to the XMIReferenceProvider constructor. no need for the
extra parameter.

Regards,

Ronald

-----Original Message-----
From: Martin Matula [mailto:[email protected]]
Sent: Thursday, July 25, 2002 11:25 PM
To: [email protected]
Subject: Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces


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]




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