RE: [hyades-dev] Proposal for embedded annotations in Test Model

[Joseph P Toomey <jptoomey@xxxxxxxxxx>]

Hi Frank.

I certainly share your concern about
CM issues -- that's why I was concerned about the paths shown in Marius'
first e-mail (until he explained the context).  I'm not advocating
absolute pathnames as the proper way to specify external annotations.  What
I was saying below was that one could create a platform URI (which describes
a path to a file that resides in a workspace -- i.e. it specifies the project
and the path within the project ), or a file URI (which is really an absolute
path, and if you chose to use it, that's obviously a bad idea.)

Accommodating relative paths to external
annotations (where the locations of those files would be relative to the
location of the resource containing the object that is annotated) would
certainly be nice.  However, since the whole point of this proposal
is to accommodate internal annotations, we need to utilize relative URIs
to specify the location of files within the current resource.  So...
the only use case that we're not capturing well with this proposal (I believe)
is a non-project-based resource that wants to utilize external annotations.
 In this case, they'd be forced to use file URIs for external annotations
(which would contain fully qualified paths.)  Is this an issue for
anyone?

One possible way to address this shortcoming
would be to use EMF's extended URI implementation to reference contained
(internal) annotations using a JAR-scheme URI instead of a relative URI.
 The big drawback there is that a JAR-scheme URI must contain a fully
qualified path to the JAR file (in our case, the XMI zip file), and storing
that path is not an acceptable solution.  The only way to get around
this would be to store an invalid URI, and then fix it up to make it valid
when the file is loaded.  This seems quite objectionable to me at
a data model level, so I'm not proposing it.

Thanks,
--Joe

Joe Toomey 
Advisory Software Engineer
Rational Software
IBM Software Group 
tel: (781) 676-7668 
fax: (781) 676-7640

Frank McGrath/Lexington/IBM@IBMUS
Sent by: hyades-dev-admin@xxxxxxxxxxx

04/13/2004 11:57 AM

Please respond to
hyades-dev@xxxxxxxxxxx

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

Joe - isn't  using absolute pathnames a bad idea for external?  Or
is it "absolute within the project"?   Given multiple machines
and CC, truly absolute paths would differ on each machine?

Frank

Joseph P Toomey/Lexington/IBM@IBMUS
Sent by: hyades-dev-admin@xxxxxxxxxxx

04/13/2004 10:58 AM

Please respond to
hyades-dev@xxxxxxxxxxx

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

I have no problem with adding an additional notion of type to the annotation.
 I'll add it to the proposal. 

I also like the idea of accommodating external annotations, but I'm concerned
about the implications of the "path to model resource" and "resource.zip"
portions of the URI.  If I understand the proposal correctly, every
URI referring to a contained (non-external) annotation would contain the
fully qualified path (excepting the device) to the resource that it is,
itself, contained in.  This would mean that anytime a resource was
renamed or moved (or checked into version control and checked out into
a different directory structure), all the URIs within the resource would
be invalidated. 

If this is correct, then I would hope to come up with a different mechanism
for specifying external annotations.  Perhaps we can propose that
the URI is relative if the annotation is contained, and absolute if the
annotation is external.  We can then use EMF's URI facility to determine
whether a given URI is absolute or relative, and thus infer whether the
annotation is contained or not.  Absolute URIs could be platform URIs
(i.e. the file is in a project in the workspace), or could be file URIs
(containing fully qualified path data.)  If we went with this approach,
I think we'd want to insulate the user of the annotation class from this
knowledge as much as possible by providing a wrapper methods that use URI
facilities like toFileString() to get access to the raw file.

Mike & Marius -- what do you think? 

Thanks. 
--Joe 


Joe Toomey 
Advisory Software Engineer
Rational Software
IBM Software Group 
tel: (781) 676-7668 
fax: (781) 676-7640

Michael.Norman@xxxxxxxxxxxxx
Sent by: hyades-dev-admin@xxxxxxxxxxx

04/13/2004 10:33 AM

Please respond to
hyades-dev@xxxxxxxxxxx

To	hyades-dev@xxxxxxxxxxx
cc
Subject	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     



_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev

ForwardSourceID:NT00013F1E     
ForwardSourceID:NT00013F4E