Re: Comparing two models for differences

Hi Brian,
problem with ordering is that for some collections MDR uses HashSet to 
optimize for performance. Ordering the output for each operation would 
be counterproductive. One solution to this problem could be to implement 
ordering outside of MDR in XMI writer. This way the writer will preserve 
ordering with any JMI service (not only with MDR).
For some usecases it could be also better to use "metamodel-based diff", 
which is a utility that operates on MDR directly rather than on XMI 
files and compares two different datastructures using their metamodel. 
One of my students developed such a module for NetBeans as part of his 
master thesis. Hopefuly he will contribute it soon.
Martin

Brian Smith wrote:
> I want to write a unit test that does the following:
>     1. Read a MOF model into an extent using XmiReader
>     2. Write the model to a SSM file using my "SSM writer".
>     3. Read the SSM file back into another extent using my "SSM reader".
>     4. Write the model to another SSM file using the "SSM reader" again.
>     5. Verify that steps #2 and #4 result in identical files using
>        the unix "diff" command.
> 
> (Note: "SSM" is the temporary name for the concrete textual syntax that 
> I am developing).
> 
> Currently, I am doing steps #1-#4 automatically, but I have to manually 
> inspect the results of "diff" myself. I am getting diffs that look like 
> the one below. The problem is basically that MDR is giving me the "root 
> nodes" in an indeterminate order. Obviously, that is not incorrect, but 
> it would be nice if MDR would at least provide "best effort" in 
> preserving the ordering of _all_ collections, whether they are 
> explicitly marked isOrdered=true or not. In other words, treat all 
> multiplicities as though isOrdered=true. What do you think?
> 
> Another similar use case:
> 
> Currently, you can't use XMI files as "golden files" in unit tests for 
> the same reasons I can't use diff to compare my "SSM" files (perhaps 
> among other reasons, such as the way xmi.id's are generated).
> 
> Another similar use case:
> 
> Lets say that I'm using MDR to manipulate XMI files. I want to store the 
> XMI files in version control with CVS. In that case, "best effort" 
> preservation of the ordering of unordered collections is necessary; 
> otherwise, CVS and "diff" will likely report many more differences (and 
> conflicts) than actually exist. I know that Novosoft implemented 
> something special in the XMI reader/write to handle this scenerio, 
> although maybe they only made an effort to preserve the xmi.id's.
> 
> Thanks,
> Brian
> 
> Example diff (notice that the only difference is that the packages 
> PrimitiveTypes and CorbaIdlTypes are reversed in order):
> 
> -package PrimitiveTypes
> +package CorbaIdlTypes
>  {
> -   tag "*tag" : javax.jmi.packagePrefix = 'javax.jmi' on ::PrimitiveTypes
> -   primitive type Boolean
> -   primitive type Integer
> -   primitive type Long
> -   primitive type Float
> -   primitive type Double
> -   primitive type String
> +   tag "*tag" : javax.jmi.packagePrefix = 'javax.jmi' on ::CorbaIdlTypes
> +   primitive type CorbaOctet
> +   primitive type CorbaShort
> +   primitive type CorbaUnsignedShort
> +   primitive type CorbaUnsignedLong
> +   primitive type CorbaUnsignedLongLong
> +   primitive type CorbaLongDouble
> +   primitive type CorbaString
> +   primitive type CorbaChar
> +   primitive type CorbaWChar
>  }
> 
>  package Model
> @@ -322,17 +325,14 @@
>     }
>  }
> 
> -package CorbaIdlTypes
> +package PrimitiveTypes
>  {
> -   tag "*tag" : javax.jmi.packagePrefix = 'javax.jmi' on ::CorbaIdlTypes
> -   primitive type CorbaOctet
> -   primitive type CorbaShort
> -   primitive type CorbaUnsignedShort
> -   primitive type CorbaUnsignedLong
> -   primitive type CorbaUnsignedLongLong
> -   primitive type CorbaLongDouble
> -   primitive type CorbaString
> -   primitive type CorbaChar
> -   primitive type CorbaWChar
> +   tag "*tag" : javax.jmi.packagePrefix = 'javax.jmi' on ::PrimitiveTypes
> +   primitive type Boolean
> +   primitive type Integer
> +   primitive type Long
> +   primitive type Float
> +   primitive type Double
> +   primitive type String
>  }
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]