[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [hyades-dev] Proposal for embedded annotations in Test Model
Joe,
 
To insulate the access to the content you could add on the annotation class an operation like (see java.net.URL.getContent()):
 
public final Object getContent(Class[] classes)
 
so the user can have access to the content transparently. You could also have a utility class that will be used in the implementation of getContent() method (as you mentioned bellow).
 
Thanks!
 
Marius Slavescu
Test and Analysis Tool Enablement, IBM Toronto Labs
phone:905-413-3610, mailto:slavescu@xxxxxxxxxx
fax: 905-413-4920
IBM Canada Limited.
8200 Warden Ave.
Markham, Ontario L6G 1C7
 
 
 
Tuesday, April 13, 2004 11:06 AM
To: hyades-dev@xxxxxxxxxxx
cc:
From: Joseph P Toomey <jptoomey@xxxxxxxxxx>
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