RE: [Mged-mage] Java MAGEstk and order of objects in dimensions

[Miller, M. (Rosetta) <Michael_Miller@Rosettabio.com>]

Hi Kjell,

> endDocument(), I guess the unresolved container could simply 
> be a list or 
> a vector instead of a stack ? Traversing them from first to 
> last element 
> would then keep the original order of the elements.

This certainly sounds like the right idea (and ArrayList is more efficient
than Vector).  

I took a look in the xmi and found that, besides the dimensions, the
following are also specified as ordered:
The association Treatments from BioMaterial to Treatment
The association ProtocolApplications from BioEvent to ProtocolApplication

and that appears to be it.

thanks,
Michael

> -----Original Message-----
> From: Kjell Petersen [mailto:kj...@ii...] 
> Sent: Monday, July 07, 2003 8:40 AM
> To: Mged Mage list at SourceForge
> Subject: [Mged-mage] Java MAGEstk and order of objects in dimensions
> 
> 
> 
> Hi all,
> 
> An unwanted "feature" of Java MAGEstk that's probably useful 
> to know about:
> 
> - The order of objects in container classes may be reversed if not 
> resolved immediately during parsing.
> 
> When parsing a MAGE-ML document, MAGEstk puts any unresolved 
> references on 
> a stack, and does a final attempt to resolve them when the end of the 
> document is reached, since the referenceed objects may have 
> been parsed 
> after the first reference to them.
> 
> Currently the stack gets emptied with pop(), as is usual for 
> stacks :), 
> but this have the side effect that references are resolved 
> and added to 
> the model in the reverse order compared to the order they 
> were parsed. In 
> most cases this may not be important, but for dimensions and 
> maybe some 
> other containers, the order of the objects is crucial.
> 
> I discovered this when I saw that after parsing the feature 
> ids/reporter 
> infos were reversed, but not the data itself...
> 
> For a valid self-contained MAGE-ML object this is not a 
> problem, since the 
> DTD specifies that Feature, Reporter, BioAssay, QT etc has to 
> be specified 
> before the dimension objects, so references in dimension 
> objects will be 
> resolved immediately, and never reach the stack.  
> 
> However if the document does not contain the referenced Feature 
> etc objects, that is references remain unresolved, empty 
> objects will be 
> added to the dimensions in reverse order, and not match the 
> right index 
> with respect to the data... In case of multiple files, 
> related problems 
> are even more likely to occur.
> 
> I haven't thought of other types of container-like objects in 
> MAGE that is 
> depending upon the ordering of the contained objects, but 
> maybe there is ?  
> 
> Since the unresolvedStack only is filled up during parsing, and then 
> accessed for the first time in the attempt to resolve the 
> references in 
> endDocument(), I guess the unresolved container could simply 
> be a list or 
> a vector instead of a stack ? Traversing them from first to 
> last element 
> would then keep the original order of the elements.
> 
> I've replaced the few necessary lines in my local copy 
> of MAGEContentHandler.java, and it seems to work. If anyone 
> wants to check 
> it into the CVS, drop me a mail.
> 
> Cheers,
> Kjell 
> 
> 
> -- 
> Kjell Petersen
> Researcher
> 
> Computational Biology Unit                  Bioinformatics group
> Bergen Center for Computational Science     Department of Informatics
> Unifob A/S                                  University of Bergen
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites 
> including Data Reports, E-commerce, Portals, and Forums are 
> available now. Download today and enter to win an XBOX or 
> Visual Studio .NET. 
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06
1203_01/01
_______________________________________________
Mged-mage mailing list
Mge...@li...
https://lists.sourceforge.net/lists/listinfo/mged-mage