Subject: Re: Kernel config file
To: Johnny Billquist <bqt@softjar.se>
From: Simon Truss <simon@bigblue.demon.co.uk>
List: tech-kern
Date: 06/18/2007 21:50:38
Johnny Billquist wrote:
[snip]
> In most cases, I don't see much advantage with XML. It's mostly being
> pushed since it's "cool". I was asking if anyone can tell my why it's
> good apart from being "cool". I haven't seen an answer to that question
> yet. What I do know is that files grow considerably larger with that
> format, and it becomes much trickier to edit with a text editor.
>
> You may call it XML, HTML or Foobar, for all I care. It's not the exact
> name or syntax I'm asking about, it's the general way of storing
> information. Is there really any advantage to it? And what, in that case?
The DTD offers syntax checking without writing any code. semantic errors
are then easier to isolate and limit their effect.
on its own XML is not that useful. when combined with xsl, dtds etc it
becomes a much more powerful tool. Its also pointless to use xml for
data lacking stucture. This should be a point for discussion.
I will re-interpret David Brownlee's useful comments in light of my
thoughts here.
"Do we want to encode structured information and will the use of it
become more numerous, diverse, and/or complex over time" From the
followups to his post I would say this is a yes.
Quentin Garnier pointed out that proplib supports other codecs. I think
xml is highly suited for external helper tools and machine access, why
not use a different codec for human editing?
> The answer about having tools that can modify the parts they know and
> understand, while leaving the rest alone can hardly be it. It's no more
> difficult to write a program that sucks in normal text lines, and just
> write them out again unchanged if they aren't recognized.
You are quite correct if there is little or no structure to the
processed information. If thats not the case, then xml for these tools
helps lower the cost of developing that tool and allows the editor to
constrain changes to those meaningful to that particular subsystem. xml
libraries assist the syntax checking so the coder can focus on semantic
checking and the editing functionality.
the tools available to help manipulate xml data make it easier to
achieve more powerful ways of managing and manipulating information.
If you mandate a custom flat file format you either force the user to
use only a text editor for now and forever or require other developers
to write conversion programs that need updating with every addition to
the file format.
proplib at least allows a choice of format and as such I would always
want an option to edit a low level format by hand. At the same time If
Im not 100% confident in my knowledge of the whole system I would
welcome a tool that can constrain my choices to only those considered
sensible. Unix has always been about choice and flexibility and I think
proplib offers a great deal of that now and even more in the future.
MS for example provide access to only the constrained interfaces and
then often compound the mistake by automating some decisions and
offering no way to override them. I think proplib offers a great balance
at the right level in the system to build those tools that make life
less complicated and easier for those that want it.
cool is when netbsd ships xml configs with matching xsl and javascript
files so we can edit configs in a web browser with syntax and semantic
checking built in :-)
Simon