> An alternative is redefining the XML a little bit, as I mentioned in
> my previous note to GHudson. That would remove the need for the XML
> to be driven in a depth-first manner.
Incidentally, I have no problem with redefining the XML format if
that's what people decide is best. (I pointed out this option in one
of my original notes.) Greg Stein's idea of specifying full directory
paths is one option; another option more along the lines of the editor
interface would be to specify identifiers for directories and files
(just like we have batons in the editor interface):
<delta-pkg id="root">
<add-dir parentid="root" id="d1"/>
<add-file parentid="d1" name="iota" id="f1"/>
<text-delta id="f1"> some file1 data </text-delta>
<close-file id="f1"/>
<add-file parentid="d1" name="iota" id="f2"/>
<prop-delta id="f2">
<set name="color">blue</set>
<set name="animal">tiger</set>
</prop-delta>
<replace-file parentid="root" name="file3" id="f3"/>
<close-dir id="d1"/>
<close-dir id="root"/>
<text-delta id="f2"> some file2 data </text-delta>
<text-delta id="f3"> some file3 data </text-delta>
<close-file id="f2"/>
<close-file id="f3"/>
</delta-pkg>
Of course, the XML parsing code would have to maintain tables mapping
identifiers to file and directory batons (it already has to do this
for text-delta-refs), which might be a pain. But it would translate
very nicely into editing function calls and wouldn't restrict the
order of traversal.
Received on Sat Oct 21 14:36:10 2006