Re: DOM and SAX parsing in Ada

[Nick Roberts <nick.roberts@acm.org>]

"Marc A. Criley" <mcNOSPAM@mckae.com> wrote:

> Ah, I see now.  Frankly, I can see both parties' points.
> 
> On the one hand, it's certainly a good thing to improve (or create) the
> documentation or commenting of a product.  And one certainly wants to
> commend and encourage any programmer motivated to do that :-)
> 
> On the other hand, any change to a piece of software could accidentally
> modify it in an unintended way.  Obviously not the addition of the
> comments themselves, but for instance if a block of comment text were
> being cut and pasted, a slip of the mouse could accidentally pick up an
> adjacent line of code and move it.  Bad things could then happen, which
> might now show up right away if this happened on a code path that is
> infreqently executed.
> ...

I agree entirely, and the changes I wanted to make -- and I made this clear
to the AdaCore employee -- were precisely designed to obviate this problem,
by allowing the maintenance documentation to be placed in separate files.
The changes I wanted to make were to place commented tags in the source
code, so that the external documentation could readily refer to fragments of
code (by tag).

It was this approach which the employee specifically rejected. The essence
of what he said was that: no maintenance documentation was necessary (the
source code was self-documenting); in any case, any such documentation
should be entirely in the form of comments in the source code. I think he is
seriously wrong on both counts.

> I suspect the AdaCore employee in question (to whom I've submitted bug
> reports that have been accepted and the fixes for which I know have been
> incorporated) feels much the same way, but for him you also have to add in
> the time that it would take to verify your updates for accuracy and to
> ensure there was none of the accidental modifiation that I mentioned
> above, which takes time away from his other AdaCore business tasks.
> 
> So he has to weigh (time to verify update and not work on functional bugs
> and improvements + risk of unintended modification) versus (value of
> documentation update with no improved functionality).
> 
> He's not being unreasonable, just weighing dollars versus benefit.

Yes, but that's not the issue.

The issue is whether I should:

   (a) create a fork of Ada/XML and develop it;

   (b) create a new Ada XML DOM package from scratch, and develop it;

   (c) design and create a new Ada XML I/O package, and develop it.

My objectives are:

   (1) to provide an Ada XML I/O package which I can use for my own specific
       purpose (a literate programming 'reverse tangle' tool);

   (2) to make this package available for the benefit of the Ada community.

Regarding objective (1), I need a package that can read a DTD (a very big
and hairy one, in fact) and expand the general entities declared in it.
Validation would also be nice. XML/Ada version 1.0 doesn't support all the
functionality I need (nor validation) -- and it has no maintenance
documentation.

-- 
Nick Roberts