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