CFD: XMLification of NOTES

[Eivind Eklund]

On Tue, Mar 30, 2004 at 02:56:44PM +0300, Alexey Zelkin wrote:
> On Tue, Mar 30, 2004 at 08:46:18AM +0000, Eivind Eklund wrote:
> > On Sun, 28 Mar 2004, Alexey Zelkin wrote:
> > > At this point I would like to start some kind of discussion and listen for
> > > your ideas which features you'd like to see in application which will be
> > > handling these XMLs.
> > 
> > I'd like to not have XML, please.  XML is hard to read - there is way
> > too much repetition compared to content.  If you have to change the
> 
> You will be able to generate text-only LINT or NOTES and use old format
> for reading.

This helps somewhat, but we really need to have that auto-generated (ie,
not an extra user action) to provide convenient access.

> > syntax, please use something more lightweight than XML (or make
> > absolutely sure we do not have to deal with the XML at the source level
> 
> I do not see any point to invent any other formats in days when XML
> become de-facto standard for such kind of information.

Repeat: XML is hard to work with in a standard text editor.  Not
infinitely hard to work with, but hard to work with.

This is *a* reason.  Whether it is a sufficient reason for this
particular design I don't know - I've not done a goals/options analysis
for this case.

There are clear costs to switching to XML - the format is worse to work
with (in a text editor) than what we have today (thus losing developer
attention on the file and eating time from those that do chose to work
with it), it has issues with version control (the diffs
are harder to read), it generates a flag day in the VC history (ie,
annotate doesn't pass through it, etc), it requires retraining of users
and change to the tools they have, it outdates documentation all over
the web (and that outdated documentation will stick around), etc.

If there are benefits to the switch (and to explictly selecting XML as a
format) that exceed these costs: Sure, go for it.  But *please* -
evaluate those benefits carefully, *and seriously evaluate the costs and
benefits of using a good format*.  XML isn't a good format for something
that will be treated as text by most readers/writers, "defactor
standard" or not.  The benefits of following a defacto standard might be
high enough that it is a decent path even though the standard itself has
problems - but grabbing for the standard on reflex is a bad idea when
the standard is bad.

> > in any way except when adding or removing devices/options to/from the
> > source tree.)
> 
> You will need to modify XML file only,

This was a constraint on WHEN it could be needed to modify the XML file.

Eivind.