Re: proplist [was: Importing xmlgrep into base]

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

At Sat, 17 Apr 2010 16:42:33 +0300,
markucz%gmail.com@localhost wrote:
> 
> > 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.
> I don't mean to step on anyone's toes, but this doesn't change the problem, it
> just adds one more layer to it. There's XML and there's proplib's subset.
> There's xml$foo which produces proplib XML, and nothing else to one-way
> convert XML to proplib XML. The external tool approach doesn't work, because
> one would like to be sure proplib stays as it is before writing such a tool.
> If it's a part of the xmltools suite though, this argument won't be valid any
> longer and everything will be just fine, I guess.

Yeah, I think, from a conceptual point of view, your argument is quite
right. But I also think --- and although this is going to make some
people scream because of the "clean design" principle and all --- the
XML subset I describe in xmltools(7) (basically: standalone
UTF-8-encoded XML with no doctype declarations, no entities except the
builtin ones, and no CDATA sections), which is what is output by all
xml* tools is really so basic that any XMLish tool, including
proplib(3), ought to support it. And it is possible to convert any XML
document set (I say "set" because of external entities and other
headaches mandated by the XML spec) to an equivalent standalone XML
document using only that subset.

I know it sounds like a dirty approach, put like that, but we could
just make it a bit more formal, and then say "all our tools and libs
dealing with XML stuff must support at least that subset", include
a tool to convert full XML to that subset, and be done with it.

Why don't we just include full XML support in proplib(3), then, you
may ask. Well, as I've said in another post (the thread is getting
long...), I think it's unrealistic. The W3C XML spec includes things
like composite documents that need to fetch pieces over the network,
and relative URL resolution (which doesn't make sense when you're
dealing with a stream, which obviously has no URL). Now, if we do away
with that, then we don't support "full XML" already (only standalone
XML), so I'm not sure it's worth trying to get "full standalone XML
support" anyway. Supporting the whole standard gives us some guarantee
that we won't need an external tool in any case. But if we're already
not supporting parts of it, the guarantee weakens and there would be
a need for an external tool anyway; that's why I'm a bit skeptical
about pushing for a better/real XML parser in proplib(3).

> > 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).
> Great to hear that.
> 
> Once again, I'm opposed to XML in this particular case, not to xmltools. It's
> like using a sledgehammer to fix a nail. That's what my infallible gut feeling
> (TM) tells me.

Honestly, I'm quite neutral about this matter. Obviously, I wasn't
there when the plist debate took place. From what I can see, there was
a need for a format, and a format was chosen; now I doubt any given
format can make everybody happy, and I don't know whether it was
a good choice, but I think it's better than nothing.

Still, I understand that you're saying that all this, anyway, is
really sick, and that we could have avoided this very question of
whatever XML subset should be supported, had we not chosen XML.

As for me, I was told that my tools should support plists well, and so
I tried to make it as nice to work with as I could. And I'm thankful
to you for pointing out that the debate is more about XML and its uses
than it is about xmltools, really...