Dear Dave & all,
From what I have seen in the XML apps the main benefit seem to be let the
data worry about the formatting itself. I am not a big C programmer but have
tried to do some similar thing in PERL. For example this might be typical
using XML:
package simulation;
# .... stuff ommitted .....
sub Parse {
my ($self, $file) = ._;
my $opts = [ "task", "object", "include"];
my $xml = new XML::Simple(forcearray => $opts ); # XML::Simple is an
example of readily available XML parsers, and it uses C library expat for
actual parsing
# read XML file
if (my $data = $xml->XMLin($file) ) {
$self->{data} = $data;
Debug "Input XML parsed successfully";
return 1;
}
else {
Error "Failed to parse simulation input XML";
}
}
This will actually work for typical XML format (sufficient for common
modelling studies) , and the program did not have one line specifying the
format of the XML format, but the data is all stored in the hash data
structure $self->{data}.
Attached is and example XML file and the data structure extracted (just a
prototype model)... See the XML file defines its own data structure and the
resulting $self->{data} reflects that - and this type of data structure might
be perfect for things like topology and protein forcefield?
-Feng
On Mon, Apr 03, 2006, Feng X Zhou wrote:
> could XML format be a possible future candidate for Topo, param, or even
> Coordinates?
>
> It would seem like a great simplifier of the parsers (if all config &
> input data is in XML), only one parser would be needed using readily
> available XML libraries and the proram just need to deal with the data
> structures rather than formats, and it is human friendly.
This comes up from time to time, but there are no current plans to go in this
direction. We generally try avoid file format changes unless there is a
strong reason to change. For one thing, no only do *we* have to write and
test new code, but many other programs that use our formats would have to do
that as well. So, the proposed benefits would have to be quite substantial.
Two other points:
a. Someone would have to do it;
b. We would have to really understand the innards of the
"readily available XML libraries". We are already struggling with
having Amber depend on the netCDF libraries. We have to make
sure that our program can be ported to a very wide variety of platforms,
including high-performance sites that don't even exist right now.
So we can't afford to become dependent on something we don't really
understand....
...regards....dac
(See attached file: sim_input.xml)
(See attached file: sim_test.out)
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Apr 05 2006 - 21:28:16 PDT
