Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [hyades-dev] Proposal for embedded annotations in Test Model

I'm not pushing back on the use of these external resources. Defining 
the annotation as an externally-typed resource does seem the right thing 
to do because there will always be "comments" we can't actually handle 
in the models.
 
I don't have a clear view on Marius's idea here about generic URIs.  It 
seems likely to cause some problems in that the resources are not 
contained in the project, but for some purposes that may be right (i.e. 
you might expect to compare the outcome of a test to some dynamic 
external resource rather than a static one).
 
If we just rely on the filename extension there is likely to be some 
conflict when differently-sourced .log or .xml files are referenced in 
the same model. Intuitively the name of the annotation is not the right 
place to put the additional qualification because this may be something 
the user sets and expects to be able to control in an arbitrary fashion. 
Some additional typing visible in the model is likely to help us down 
the line when we get the editors to implement extension points which 
look at this stuff, and allow some kind of consistency with the other 
typed data in the model.
 
 
 
 -----Original Message-----
From: slavescu [mailto:slavescu@xxxxxxxxxx]
Sent: Tuesday, April 13, 2004 2:57 PM
To: hyades-dev
Subject: Re: [hyades-dev] Proposal for embedded annotations in Test 
Model




Joe, 

I have a suggestion related with the URI, you could have a fully 
specified URI (not only relative to the resource), then you could 
differentiate embedded versus linked (external) annotations. 
I had in mind this approach when I was trying to split the content of a 
resource in separate content files in the same XMI ZIP resource file by 
using the query portion of the URI in order to select the right content 
file. 

Here is an example: 

        URI to object: /.../path_to_model_resource/resource.zip#objID 

        URI to embedded annotation: 
/.../path_to_model_resource/resource.zip?annotationID=/internal_path_to_
annotation_file/Annotation1.gif 

        URI to a linked (external to the model resource) annotation: 
/.../path_to_annotation_file/Annotation2.gif 

were /.../ represents the prefix of the URI (scheme,device, etc), objID 
can be flat or hierarchical ID and internal_path_to_annotation_file 
could follow your schema (annotation folder + objID + 
annotation_file_name). 

Thanks !
Marius




Joseph P Toomey <jptoomey@xxxxxxxxxx> 
Sent by: hyades-dev-admin@xxxxxxxxxxx 

04/13/2004 08:16 AM 
Please respond to
hyades-dev


To
hyades-dev@xxxxxxxxxxx 
cc
Subject
Re: [hyades-dev] Proposal for embedded annotations in Test Model

	





Thanks for your quick response, Mike. 

Since the annotations are files, the intent is that the extension of the 
file name indicates the file's type.  We aren't inferring any type 
information from the test type -- any test type can have an arbitrary 
number of different types of annotations.  Any viewer/editor should be 
able to determine whether or not they can deal with a given annotation 
based on the file's extension.  In the Hyades 3.0 release, we may not 
expose these annotations via the Hyades test UIs, although a reasonable 
stretch goal is to show the presence of annotations within the editors, 
and allow an annotation's file to be opened using the default eclipse 
editor.  Obviously, you could implement more sophisticated behavior in 
your own editors/viewers, as well as within the base Hyades 
editors/viewers over time. 

In addition to having the filename as part of the URI, each annotation 
also has a name (distinct from the filename), which should be used by 
the author of the annotation to appropriately name the annotation.  I 
think it would be worthwhile to enumerate and document the names that we 
expect to use, but again, the type information will be available as part 
of the filename in the URI. 

Please let me know if this addresses your concern, and thanks again for 
the quick response. 

--Joe 

Joe Toomey 
Advisory Software Engineer
Rational Software
IBM Software Group 
Mike Norman <Michael.Norman@xxxxxxxxxxxxx> 
Sent by: hyades-dev-admin@xxxxxxxxxxx 

04/13/2004 05:49 AM 

Please respond to
hyades-dev@xxxxxxxxxxx

To
hyades-dev@xxxxxxxxxxx 
cc
Subject
Re: [hyades-dev] Proposal for embedded annotations in Test Model


	





My reading of this is that according to the current proposal if an 
alternative viewer/editor opens up the model, all it sees is a URI, it 
can't know wether or not it can deal with the annotations that are 
there. At te moment I assume that the editor will branch off the test 
type, but can we at this stage simply put some type information. in the 
model relating to the annotation so that we stand a chance of dealing 
with them in a more flexible way in later versions?

Joseph P Toomey wrote: 

Attached is a short proposal for adding embedded annotations to the Test 
Model.  This is a feature request that we have received from several 
consumers, and would like to implement for Hyades 3.0.  In order to do 
this, we need to close on this design very quickly.  I ask everyone from 
the Test Model team to please review this proposal (it is less than a 
page in length), and respond with any concerns about the proposal.  I 
have discussed the details of the proposal with Harm, and he is in 
agreement with this approach for adding annotations to model elements, 
and with the desire to provide a test model annotation solution in the 
3.0 timeframe. 

As you know, we are all driving hard to meet our 3.0 deadlines.  In 
order to get this feature integrated in time, we need to close on the 
design before this week's test model meeting.  Please use the mailing 
list to discuss any concerns.  In the absence of feedback, I will assume 
that the test model team is in agreement with this proposal. 



Thanks for your attention, 
--Joe 


Joe Toomey 
Advisory Software Engineer
Rational Software
IBM Software Group 

ForwardSourceID:NT00013EB6     





Back to the top