Re: proplist [was: Importing xmlgrep into base]

[Nhat Minh Le <nhat.minh.le%huoc.org@localhost>]

At Fri, 16 Apr 2010 15:56:20 +0300,
markucz%gmail.com@localhost wrote:
> Now, imagine there's some general purpose tool which takes some input and
> spits out a corresponding XML representation. Imagine someone uses this
> hypothetical tool to generate proplib plists. To me, at least, this sounds
> plausible. Now, how can you be sure proplib won't bite you in the ass (as has
> already happened in 4.0, see e.g. [1]) and refuse to handle the tool's output
> without problems? You can either
> a) change the tool to also emit proplib's XML subset and add logic when it
> should do so; or
> b) change proplib to understand all of XML.

c) Use an external tool to convert to the XML subset supported by our
internal tools. That's what I proposed in my other e-mail, and IMHO,
the best solution.

> Point a) is acceptable if the number of such tools is small. Point b) is
> probably the right thing to do but requires proplib to be extended / fixed /
> partially rewritten. Admittedly, changing proplib's format to something else
> will also require proplib to be (perhaps significantly) changed and a new
> library written to replace libregxml. XML by itself is fine. The point is
> [...]

Just for your information: libregxml wouldn't need to be replaced, for
the most part. As I've said in another post, the XML-specific parsing
is in regxml_xml(3). The core algorithm implemented in regxml(3) is
a generic tree matching algorithm and is suited to whatever tree-like
data format you want, provided you write the parser/printer to go with
it.