One thought that occurred to me is that you could utilize a virtual filesystem to expose the drawing database in a simply accessible way. The basic idea is that a program built to query the data and make simple adjustments to it would be capable of assuming that everything is static data with no relationships or associativity to be broken. It would be shown the fully-resolved coordinate data for all geometry rather than a bunch of "see-also" style relationships and links. For protecting the integrity of the associative data, a read-only attribute could be set on all parametric data. This is the same as write permission on a typical filesystem. If you go to the trouble to check for permission, you can have your Perl script die when it fails to open a file for writing. If not, you can just allow it to silently fail to write the data. It is up to the programmer how they want to handle it, but the system presents them with a set of well-defined options. With the following code, all of these methods are valid, provided that the programmer fully intended the consequences of checking or not checking for write permission. # open a file without checking for write permission: open(OUT, ">$outfile"); # silently fails (which is sometimes okay) print OUT "$data"; # now to throw a critical error: open(OUT, ">$outfile") or die "can't open $outfile!"; # maybe we only write if we have permission: if(-w $outfile) { open(OUT, ">$outfile"); print OUT "$data"; } # or possibly there is a better place to write the data: if(-w $outfile) { $out = OUT; open($out, ">$outfile"); } else { $out = STDOUT; } print $out "$data"; # and with some more complexity, the data could be handled # in a standard way which would need to be pre-established: if(-w $outfile) { $out = OUT; open($out, ">$outfile"); } else { $out = $info_out; # a pre-established handle } print $out "$data"; --Eric