RE: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces

Hi Martin & Daniel,

Yes, I like that proposal.

Martin,
the name documentURI suggests a URI :). In your answer to Brian about any
restrictions on the, at that time, called XMIReference.getReference()
method, you said no. With this new proposal we go in another direction, by,
at minimum, suggesting a format. Note, that I do not mind this.  

Regards,

Ronald

-----Original Message-----
From: Martin Matula [mailto:[email protected]]
Sent: Friday, July 26, 2002 10:24 AM
To: [email protected]
Subject: Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces


Hi Ronald,
what do you think about the proposal that Brian just made. (To change 
XMIRererence to return documentURI and xmi.id? This solution seems 
cleaner to me and you would not need to create a new instance of 
XMIReferenceProvider for each document.
Martin

Krijgsheld, Ronald wrote:
> 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]
> 
> 




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