Re: proplist [was: Importing xmlgrep into base]

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

At Thu, 15 Apr 2010 20:24:58 -0400,
Martin S. Weber wrote:
> 
> On Tue, Apr 13, 2010 at 11:40:12PM -0400, Matthew Mondor wrote:
> > On Tue, 13 Apr 2010 18:49:28 -0400
> > "Martin S. Weber" <Ephaeton%gmx.net@localhost> wrote:
> > 
> > > Which really makes one wonder why proplib uses a half-baked 
> > > XML format anyways. Pity s-exp weren't used back then :)
> > 
> > I prefer S-EXP to XML myself (or even JSON if for such simple data), (...)
> 
> don't get me wrong. I didn't want to state a specific preference. I think
> you missed the part which I failed to stress to make it obvious what I was
> talking about. It was the "half-baked". As we have learned/seen, what
> proplib digests isn't XML. It tries hard to make it look like it, but you're
> not guarantueed to take advantage of XML tools and have something that proplib
> can digest again.
> 
> Having a half-baked half-implementation of a standard (as ugly as it might
> be) is not very netbsd'ish IMO ("clean design first"). It makes people
> expect the wrong things.

Well, the XML tools also deal with a "half-baked" XML format,
actually. And they only ever produce a very limited subset of XML that
I'm about sure proplib(3) can digest (and if not, that can be fixed).

But there are reasons why XML support is sloppy, actually. And if you
look around, there are a lot of programs and libraries with half-XML
support out there. This doesn't mean we're all lazy programmers, it
means the standard is lacking.

My guess is that XML as its core seemed too simple so the guys at the
W3C had to add some shitty features to make it look like they were
doing something useful, but somehow some very important matters seemed
so important that they thought it'd be best to let application
developers deal with them.

So half of the unsupported features are because they're plain
unreasonable (things like "you should be able to fetch external
documents through the Internet"), and the other half is to make the
tools actually usable (things like: the standard says "all whitespace
is significant unless the application decides otherwise", which
basically means we shouldn't be indenting XML at all... so instead,
the XML tools default to discarding "seemingly irrelevant" whitespace
and indent to let the XML stay readable).

Besides, things like entities and CDATA sections should never have
existed in the first place. Their only purpose is to make typing
easier (for whom may I ask...), but since the XML tools are, well,
tools, they will never generate such things, so the output format is
only a very limited subset of XML, but that's also the subset that is
likely to be used for data interchange, in absence of human
intervention. And I think it's fine if internal NetBSD code such as
proplib(3) only supports that subset.

My plan is to have some xmlcat(1) utility that would be able to
understand the full XML standard, including the more obscure features,
and spit out a pre-digested XML stream that would be usable by all
other programs.

--
Nhat Minh