comp.lang.ada
 help / color / mirror / Atom feed
* DOM and SAX parsing in Ada
@ 2004-11-08 23:24 Tim Roede
  2004-11-09  0:24 ` David Botton
  2004-11-09  3:14 ` Steve
  0 siblings, 2 replies; 64+ messages in thread
From: Tim Roede @ 2004-11-08 23:24 UTC (permalink / raw)


There is considerable interest in the group I am working with to provide
XML parsing using both DOM and SAX parsing.  Does anyone have a name or
a link to a suitable Ada library (similar to xerces)?

Please respond using email.

Thanks in advance

timothy.j.roede@boeing.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2004-11-08 23:24 DOM and SAX parsing in Ada Tim Roede
  2004-11-09  0:24 ` David Botton
@ 2004-11-09  3:14 ` Steve
  2005-01-20 12:16   ` okellogg
  2021-11-22 13:01   ` James Hitch
  1 sibling, 2 replies; 64+ messages in thread
From: Steve @ 2004-11-09  3:14 UTC (permalink / raw)


XML/Ada

http://libre.act-europe.fr/xmlada/

Includes a Unicode module, a SAX 2.0 module, and a DOM 2.0 module.

The code is released under the GMGPL.

Support is available for a fee from AdaCore.

In addition to the platforms listed at the Libre site, I a have successfully
used XML/Ada 1.0 with ObjectAda 7.2.2.

Steve
(The Duck)


"Tim Roede" <timothy.j.roede@boeing.com> wrote in message
news:41900010.D28DD400@boeing.com...
> There is considerable interest in the group I am working with to provide
> XML parsing using both DOM and SAX parsing.  Does anyone have a name or
> a link to a suitable Ada library (similar to xerces)?
>
> Please respond using email.
>
> Thanks in advance
>
> timothy.j.roede@boeing.com





^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2004-11-09  3:14 ` Steve
@ 2005-01-20 12:16   ` okellogg
  2005-01-21 18:09     ` Nick Roberts
  2021-11-22 13:01   ` James Hitch
  1 sibling, 1 reply; 64+ messages in thread
From: okellogg @ 2005-01-20 12:16 UTC (permalink / raw)


On Nov 8 2004, 7:14 pm, Steve wrote:

> XML/Ada
>
> http://libre.act-europe.fr/xmlada/
>

Another one: aDom, http://www.calcalent.com/html/aDom/seite02.htm

-- Oliver


> "Tim Roede" <timothy.j.roede@boeing.com> wrote in message
> news:41900010.D28DD400@boeing.com...
> > There is considerable interest in the group I am working with to
provide
> > XML parsing using both DOM and SAX parsing.  Does anyone have a
name or
> > a link to a suitable Ada library (similar to xerces)?
> >
> > Please respond using email.
> >
> > Thanks in advance
> >
> > timothy.j.roede@boeing.com




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-20 12:16   ` okellogg
@ 2005-01-21 18:09     ` Nick Roberts
  2005-01-24 11:26       ` Alex R. Mosteo
  0 siblings, 1 reply; 64+ messages in thread
From: Nick Roberts @ 2005-01-21 18:09 UTC (permalink / raw)


"okellogg" <okellogg@freenet.de> wrote:

> On Nov 8 2004, 7:14 pm, Steve wrote:
> 
> > XML/Ada
> >
> > http://libre.act-europe.fr/xmlada/
> >
> 
> Another one: aDom, http://www.calcalent.com/html/aDom/seite02.htm

> > "Tim Roede" <timothy.j.roede@boeing.com> wrote in message
> > news:41900010.D28DD400@boeing.com...

> > > There is considerable interest in the group I am working with to
> > > provide XML parsing using both DOM and SAX parsing.  Does anyone have
> > > a name or a link to a suitable Ada library (similar to xerces)?

Would anyone be interested in an Ada package that parsed XML (including DTDs
and entities, with namespace support), but which was written with an
interface that is (hopefully) better suited to Ada than DOM or SAX?

I have partially written such a package. It is similar to the DOM, but
slightly higher-level, and much more Ada-friendly (I think). I am in a
quandary whether to pursue writing this package (for my own XML processing
needs) or drop it and use someone else's. If I finish it, I'd be happy to
release it under the GPL.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-21 18:09     ` Nick Roberts
@ 2005-01-24 11:26       ` Alex R. Mosteo
  2005-01-24 12:16         ` Marius Amado Alves
                           ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Alex R. Mosteo @ 2005-01-24 11:26 UTC (permalink / raw)


Nick Roberts wrote:
> "okellogg" <okellogg@freenet.de> wrote:
> 
> 
>>On Nov 8 2004, 7:14 pm, Steve wrote:
>>
>>
>>>XML/Ada
>>>
>>>http://libre.act-europe.fr/xmlada/
>>>
>>
>>Another one: aDom, http://www.calcalent.com/html/aDom/seite02.htm
> 
> 
>>>"Tim Roede" <timothy.j.roede@boeing.com> wrote in message
>>>news:41900010.D28DD400@boeing.com...
> 
> 
>>>>There is considerable interest in the group I am working with to
>>>>provide XML parsing using both DOM and SAX parsing.  Does anyone have
>>>>a name or a link to a suitable Ada library (similar to xerces)?
> 
> 
> Would anyone be interested in an Ada package that parsed XML (including DTDs
> and entities, with namespace support), but which was written with an
> interface that is (hopefully) better suited to Ada than DOM or SAX?

I for one am interested. What kind of Ada-ish interface have you in 
mind? I have already written a layer on top of Xml/Ada DOM to use path 
oriented queries.

You can check the specs at

http://deepsix.homeip.net/svn/Adagio%20head/src/agpl/agpl-xml.ads

Sadly I just see that gnatpp has lost some of line breaks in comments. 
Some switch I shouldn't have set.

> I have partially written such a package. It is similar to the DOM, but
> slightly higher-level, and much more Ada-friendly (I think). I am in a
> quandary whether to pursue writing this package (for my own XML processing
> needs) or drop it and use someone else's. If I finish it, I'd be happy to
> release it under the GPL.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-24 11:26       ` Alex R. Mosteo
@ 2005-01-24 12:16         ` Marius Amado Alves
  2005-01-24 20:17           ` Georg Bauhaus
  2005-01-24 19:02         ` Marc A. Criley
  2005-01-25 15:29         ` Nick Roberts
  2 siblings, 1 reply; 64+ messages in thread
From: Marius Amado Alves @ 2005-01-24 12:16 UTC (permalink / raw)
  To: comp.lang.ada

FWIW, here's the XML parser I wrote and have been using for many years now:

    http://softdevelcoop.org/software/xml_automaton

(I'll publish the documentation and examples soon. I have it here 
somewhere...)




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-24 11:26       ` Alex R. Mosteo
  2005-01-24 12:16         ` Marius Amado Alves
@ 2005-01-24 19:02         ` Marc A. Criley
  2005-01-25  9:50           ` Alex R. Mosteo
  2005-01-25 15:29         ` Nick Roberts
  2 siblings, 1 reply; 64+ messages in thread
From: Marc A. Criley @ 2005-01-24 19:02 UTC (permalink / raw)


Alex R. Mosteo wrote:
> 
> 
> I for one am interested. What kind of Ada-ish interface have you in 
> mind? I have already written a layer on top of Xml/Ada DOM to use path 
> oriented queries.

<plug>
XIA 0.61 (XPath In Ada) is available at www.mckae.com/xia.html.  The 
simplest form of an XPath query is a slash-separated path of element 
tags; but XPath 1.0 gives you a lot more flexibility for constructing 
queries that will pick out specific elements (and attributes) having 
specific properties.
</plug>

Oh, and a general XML and Ada request:  In this thread a number of XML 
and Ada tools and efforts have been mentioned of which I was unaware. 
Please submit the name and a summary to www.adapower.com so that David 
can add them in, and build up the repository of info for our and other's 
use.

Thanks,

Marc A. Criley
McKae Technologies
www.mckae.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-24 12:16         ` Marius Amado Alves
@ 2005-01-24 20:17           ` Georg Bauhaus
  2005-01-24 21:18             ` Pascal Obry
  0 siblings, 1 reply; 64+ messages in thread
From: Georg Bauhaus @ 2005-01-24 20:17 UTC (permalink / raw)


Marius Amado Alves wrote:
> FWIW, here's the XML parser I wrote and have been using for many years now:
> 
>    http://softdevelcoop.org/software/xml_automaton
> 
> (I'll publish the documentation and examples soon. I have it here 
> somewhere...)
> 

Let me be picky, it is a tokenizer of straightforward simplicity
for text which has some form of XML-like markup in it.
As such, it can be very useful in the construction of an XML-parser.
However, it is not an XML parser, a defined term. (You wouldn't
want to say that a Pascal fragment recognizer is an Ada compiler. ;-)

No offence intended, I'm saying this because people should not be
made believe that XML is just text interspersed with tags, which
is way off. This belief has lead to production of low quality data
streams, and to expensive fixing activities.

Georg



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-24 20:17           ` Georg Bauhaus
@ 2005-01-24 21:18             ` Pascal Obry
  0 siblings, 0 replies; 64+ messages in thread
From: Pascal Obry @ 2005-01-24 21:18 UTC (permalink / raw)



Georg Bauhaus <bauhaus@futureapps.de> writes:

> No offence intended, I'm saying this because people should not be
> made believe that XML is just text interspersed with tags, which
> is way off. This belief has lead to production of low quality data
> streams, and to expensive fixing activities.

The proof is to look at XML/Ada, far more than just a text parser ;)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-24 19:02         ` Marc A. Criley
@ 2005-01-25  9:50           ` Alex R. Mosteo
  0 siblings, 0 replies; 64+ messages in thread
From: Alex R. Mosteo @ 2005-01-25  9:50 UTC (permalink / raw)


Marc A. Criley wrote:

> <plug>
> XIA 0.61 (XPath In Ada) is available at www.mckae.com/xia.html.  The 
> simplest form of an XPath query is a slash-separated path of element 
> tags; but XPath 1.0 gives you a lot more flexibility for constructing 
> queries that will pick out specific elements (and attributes) having 
> specific properties.
> </plug>

Very interesting. To keep in mind.

> Oh, and a general XML and Ada request:  In this thread a number of XML 
> and Ada tools and efforts have been mentioned of which I was unaware. 
> Please submit the name and a summary to www.adapower.com so that David 
> can add them in, and build up the repository of info for our and other's 
> use.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-24 11:26       ` Alex R. Mosteo
  2005-01-24 12:16         ` Marius Amado Alves
  2005-01-24 19:02         ` Marc A. Criley
@ 2005-01-25 15:29         ` Nick Roberts
  2005-01-25 18:21           ` Marc A. Criley
  2 siblings, 1 reply; 64+ messages in thread
From: Nick Roberts @ 2005-01-25 15:29 UTC (permalink / raw)


"Alex R. Mosteo" <devnull@mailinator.com> wrote:

> Nick Roberts wrote:
> 
> > Would anyone be interested in an Ada package that parsed XML (including
> > DTDs and entities, with namespace support), but which was written with
> > an interface that is (hopefully) better suited to Ada than DOM or SAX?
> 
> I for one am interested. What kind of Ada-ish interface have you in mind?

It is really quite similar to DOM, but simplified and made more Ada-ish.

Most of the exported types are token types, whose values are references to
the object itself. Tokens are easily copied and passed around, and are
naturally implemented (privately) as access values. So, for example, a
document in memory is represented by the Document_Ref type, and elements
within a document by the Element_Ref type, and so on.

There is a Read procedure to read an XML document into memory (which can
read and use a DTD, performing full validation), and a Write procedure to
write out a document in memory (as a standalone XML document).

I have provided a full set of operations for querying a document in memory,
and a redcued set of operations which allow the construction (or extension)
of a document's structure (but not modification-in-place, reorganisation, or
deletion). I reckon this simplifies the interface (and the iplementation)
tremendously without much loss of usefulness, since the typical idiom of an
XML processing program written in Ada will be to traverse through one
structure, generating another structure as it goes.

I've not included anything like XPath; I don't think it would be appropriate
at the level of Ada programming. It would be easy enough to write a
procedure that iterated another procedure (as an access parameter) for each
node matching certain criteria.

I am including a convenience procedure to copy a node from one document to
another.

More later.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-25 15:29         ` Nick Roberts
@ 2005-01-25 18:21           ` Marc A. Criley
  2005-01-26  5:39             ` Nick Roberts
  0 siblings, 1 reply; 64+ messages in thread
From: Marc A. Criley @ 2005-01-25 18:21 UTC (permalink / raw)


Nick Roberts wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> wrote:
> 
>>Nick Roberts wrote:
>>
>>>Would anyone be interested in an Ada package that parsed XML (including
>>>DTDs and entities, with namespace support), but which was written with
>>>an interface that is (hopefully) better suited to Ada than DOM or SAX?
>>
>>I for one am interested. What kind of Ada-ish interface have you in mind?
> 
> It is really quite similar to DOM, but simplified and made more Ada-ish.

As one intent on exploiting the XML market with the aid of Ada, I wish 
that the developers interested in XML would work on adding to the 
Ada-XML development tool chest, rather than coming up with new ways to 
do something that's already been done.

Look, I'm not trying to tell anyone what to do, it's just that IMHO Ada 
developers are sparse, and those interested in XML even more so, so by 
doubling or tripling up doing something that's already done, it takes 
away from adding new capabilities.  Maybe AdaCore's XML/Ada isn't as 
Ada-ish as it could be, but for the most part does DOM and SAX parsing 
just fine (plus, you get the source code), and it's out there now.  If 
the XML/Ada interface is too thin, write a thick binding and release 
that, then move on to something else.

I looked at putting together an XML parser at one time, then woke up and 
realized that, duh, one already existed, so my time would be better 
spent leveraging off of it, hence XPath In Ada (XIA).

I'm just suggesting is all...don't get caught up in Not-Invented-Here 
when there's are whole fields of functionality that need Ada bindings or 
implementations.

Marc A. Criley
McKae Technologies
www.mckae.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-25 18:21           ` Marc A. Criley
@ 2005-01-26  5:39             ` Nick Roberts
  2005-01-26  7:37               ` Martin Krischik
                                 ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-26  5:39 UTC (permalink / raw)


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

> As one intent on exploiting the XML market with the aid of Ada, I wish
> that the developers interested in XML would work on adding to the Ada-XML
> development tool chest, rather than coming up with new ways to do
> something that's already been done.
> ...
> I'm just suggesting is all...don't get caught up in Not-Invented-Here when
> there's are whole fields of functionality that need Ada bindings or
> implementations.

In fact, it's because of AdaCore's 'not invented here' attitude that I
considered writing an alternative XML parser in the first place.

My understanding is that, although XML/Ada is released under the GPL, any
changes I made (or anyone not an AdaCore employee) would not be merged back
into the AdaCore branch (because that would contaminate the copyright purity
of their code, apparently). If I were to develop a copy of XML/Ada (on
SourceForge, say), it would be a permanent fork.

So, rather than create a fork, why not create a new package instead? I think
my package will be somewhat better than DOM, resulting in more concise,
readable, and efficient Ada code. I'll normally be happy to merge other
people's work into it.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26  5:39             ` Nick Roberts
@ 2005-01-26  7:37               ` Martin Krischik
  2005-01-26 12:24               ` Jeff C
  2005-01-26 14:12               ` Marc A. Criley
  2 siblings, 0 replies; 64+ messages in thread
From: Martin Krischik @ 2005-01-26  7:37 UTC (permalink / raw)


Nick Roberts wrote:

> "Marc A. Criley" <mcNOSPAM@mckae.com> wrote:
> 
>> As one intent on exploiting the XML market with the aid of Ada, I wish
>> that the developers interested in XML would work on adding to the Ada-XML
>> development tool chest, rather than coming up with new ways to do
>> something that's already been done.
>> ...
>> I'm just suggesting is all...don't get caught up in Not-Invented-Here
>> when there's are whole fields of functionality that need Ada bindings or
>> implementations.
> 
> In fact, it's because of AdaCore's 'not invented here' attitude that I
> considered writing an alternative XML parser in the first place.
> 
> My understanding is that, although XML/Ada is released under the GPL, any
> changes I made (or anyone not an AdaCore employee) would not be merged
> back into the AdaCore branch (because that would contaminate the copyright
> purity of their code, apparently). If I were to develop a copy of XML/Ada
> (on SourceForge, say), it would be a permanent fork.

Last time I send them a patch I got an answer that it would be merged in.
But since XML/Ada does not have cvs access I don't know if its true.

(If you are interested in my XML/Ada ad ons: they are part of AdaCL).

My patches for PolyORB however have been merged in - PolyORB has cvs access
so I know.

AdaCore is better then you thing.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26  5:39             ` Nick Roberts
  2005-01-26  7:37               ` Martin Krischik
@ 2005-01-26 12:24               ` Jeff C
  2005-01-26 16:16                 ` Nick Roberts
  2005-01-26 14:12               ` Marc A. Criley
  2 siblings, 1 reply; 64+ messages in thread
From: Jeff C @ 2005-01-26 12:24 UTC (permalink / raw)



"Nick Roberts" <nick.roberts@acm.org> wrote in message 
news:gemini.iawt1w000svx202ss.nick.roberts@acm.org...
>
> In fact, it's because of AdaCore's 'not invented here' attitude that I
> considered writing an alternative XML parser in the first place.
>
> My understanding is that, although XML/Ada is released under the GPL, any
> changes I made (or anyone not an AdaCore employee) would not be merged 
> back
> into the AdaCore branch (because that would contaminate the copyright 
> purity
> of their code, apparently). If I were to develop a copy of XML/Ada (on
> SourceForge, say), it would be a permanent fork.


Of course you mean to say GMGPL there...

But I am not sure why you are making that statemetn

At http://libre.act-europe.fr/xmlada/

Under the contributing header it says:

 "Contributions to this library are most appreciated, including bug 
reports."

Now, I have only ever submitted really really small things to ACT projects 
(GtkAda) and have never
been turned away.

I suspect that if it was a large contribution that perhaps they would want 
copyright papers signed in some manner (either
granting copyright to ACT or at least affirming that no other party had an 
interest).

Have you ever asked about submitting something large (or better yet actually 
tried to submit something moderate and see what happens)

I also strongly suspect that since this is a product for them that any large 
scale changes would
get a reasonable peer review along with a reasonable number of 
rejections/peer review comments that would be needed
before the item was accepted. This is all quite reasonable.

Even on some of my small patches, the level of comments about the changes 
were nearly equal to the size of the
patch in question (and all perfectly valid comments that were indicative of 
the fact they they are creating libraries for
customers and long term support and I am (in this case) working on a patch 
at 11 PM for no apparent reason in a best effort
type fashion that sometimes works out and sometimes looks like I worked on 
it at 11 PM)






^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26  5:39             ` Nick Roberts
  2005-01-26  7:37               ` Martin Krischik
  2005-01-26 12:24               ` Jeff C
@ 2005-01-26 14:12               ` Marc A. Criley
  2005-01-27  3:59                 ` Steve
  2 siblings, 1 reply; 64+ messages in thread
From: Marc A. Criley @ 2005-01-26 14:12 UTC (permalink / raw)


Nick Roberts wrote:
> 
> My understanding is that, although XML/Ada is released under the GPL, any
> changes I made (or anyone not an AdaCore employee) would not be merged back
> into the AdaCore branch (because that would contaminate the copyright purity
> of their code, apparently). If I were to develop a copy of XML/Ada (on
> SourceForge, say), it would be a permanent fork.

Well, from personal experience I can attest (and others in this thread 
have done likewise) that XML/Ada bugs I've reported have been accepted 
by AdaCore and been fixed in the code base.

(I've also submitted patches for GtkAda's Glade and those have gone 
right in as well.)

Contributions to GNAT itself might need to undergo a more rigorous 
review process before getging in, since that's AdaCore's family jewels, 
but there's ample experience with most of the other AdaCore products 
(GtkAda, GPS, ASIS-for-GNAT, and XML/Ada) demonstraing that AdaCore 
developers readily accept bug reports and patches, take them seriously, 
and incorporate them into the products.

Marc



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 12:24               ` Jeff C
@ 2005-01-26 16:16                 ` Nick Roberts
  2005-01-26 16:46                   ` Georg Bauhaus
                                     ` (3 more replies)
  0 siblings, 4 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-26 16:16 UTC (permalink / raw)


Martin Krischik <martin@krischik.com> wrote:

> > In fact, it's because of AdaCore's 'not invented here' attitude that I
> > considered writing an alternative XML parser in the first place.
> > 
> > My understanding is that, although XML/Ada is released under the GPL,
> > any changes I made (or anyone not an AdaCore employee) would not be
> > merged back into the AdaCore branch (because that would contaminate the
> > copyright purity of their code, apparently). If I were to develop a copy
> > of XML/Ada (on SourceForge, say), it would be a permanent fork.
> 
> Last time I send them a patch I got an answer that it would be merged in.
> But since XML/Ada does not have cvs access I don't know if its true.
> 
> (If you are interested in my XML/Ada ad ons: they are part of AdaCL).
> 
> My patches for PolyORB however have been merged in - PolyORB has cvs
> access so I know.
> 
> AdaCore is better then you thing.

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

> Well, from personal experience I can attest (and others in this thread
> have done likewise) that XML/Ada bugs I've reported have been accepted by
> AdaCore and been fixed in the code base.
> 
> (I've also submitted patches for GtkAda's Glade and those have gone right
> in as well.)
> 
> Contributions to GNAT itself might need to undergo a more rigorous review
> process before getging in, since that's AdaCore's family jewels, but
> there's ample experience with most of the other AdaCore products (GtkAda,
> GPS, ASIS-for-GNAT, and XML/Ada) demonstraing that AdaCore developers
> readily accept bug reports and patches, take them seriously, and
> incorporate them into the products.

"Jeff C" <jcreem@yahoo.com> wrote:

> Of course you mean to say GMGPL there...

Yes.

> But I am not sure why you are making that statemetn
> 
> At http://libre.act-europe.fr/xmlada/
> 
> Under the contributing header it says:
> 
> "Contributions to this library are most appreciated, including bug 
> reports."
> 
> Now, I have only ever submitted really really small things to ACT projects
> (GtkAda) and have never been turned away.
> 
> I suspect that if it was a large contribution that perhaps they would want
> copyright papers signed in some manner (either granting copyright to ACT
> or at least affirming that no other party had an interest).
> 
> Have you ever asked about submitting something large (or better yet
> actually tried to submit something moderate and see what happens)
> 
> I also strongly suspect that since this is a product for them that any
> large scale changes would get a reasonable peer review along with a
> reasonable number of rejections/peer review comments that would be needed
> before the item was accepted. This is all quite reasonable.
> 
> Even on some of my small patches, the level of comments about the changes
> were nearly equal to the size of the patch in question (and all perfectly
> valid comments that were indicative of the fact they they are creating
> libraries for customers and long term support and I am (in this case)
> working on a patch at 11 PM for no apparent reason in a best effort type
> fashion that sometimes works out and sometimes looks like I worked on it
> at 11 PM)

My comments are based on an e-mail exchange I had with the AdaCore employee
who was (at the time) in charge of work on XML/Ada, a couple of months ago.
His comments came as a surprise to me, in part because of what is said on
the web site ("Contributions to this library are most appreciated, including
bug reports"), but I have it from the horse's mouth, so to speak.

When I suggested that I wanted to make changes to the code, he indicated
that those changes could not be merged back into the AdaCore CVS copy unless
I signed a copyright assignment, in favour of either AdaCore or the FSF, to
the latter of which I am agreeable. When I suggested that XML/Ada be moved
to SourceForge, he indicated that it would have to be a separate project (a
fork), whose changes could never, in practice, be merged back into the
AdaCore CVS, because of the difficulty of getting all the contributors to
sign the assignment. This is to the best of my recollection and
understanding.

So, I could see very little advantage to making any contributions to
XML/Ada, since it would create two XML/Adas (mine and AdaCore's). Would that
be an advantage to the Ada community?

On the subject of comments, I suggested that the amount of maintenance
documention (in the form of comments or in any other form) was insufficient
-- it was nearly nonexistent, in fact -- and the answer was, in essence,
that no maintenance documentation is required, since the code is
self-documenting. I'm afraid, to me, that attitude is unacceptable (and
doesn't seem very professional, frankly).

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 16:16                 ` Nick Roberts
@ 2005-01-26 16:46                   ` Georg Bauhaus
  2005-01-27 19:45                     ` Nick Roberts
  2005-01-26 22:14                   ` Brian May
                                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 64+ messages in thread
From: Georg Bauhaus @ 2005-01-26 16:46 UTC (permalink / raw)


Nick Roberts wrote:

> On the subject of comments, I suggested that the amount of maintenance
> documention (in the form of comments or in any other form) was insufficient
> -- it was nearly nonexistent, in fact -- and the answer was, in essence,
> that no maintenance documentation is required, since the code is
> self-documenting. I'm afraid, to me, that attitude is unacceptable (and
> doesn't seem very professional, frankly).

Looking at the code, there are lots and lots of comments,
mostly in the specs, but also in some bodies. I have also found the
introductory sections in some of the specs instructive, if somewhat
formal.
What is it that is missing when you want to "maintain" XML/Ada?

georg



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 16:16                 ` Nick Roberts
  2005-01-26 16:46                   ` Georg Bauhaus
@ 2005-01-26 22:14                   ` Brian May
  2005-01-27  9:28                     ` Martin Krischik
  2005-01-27 19:55                     ` Nick Roberts
  2005-01-26 23:48                   ` Stephen Leake
  2005-01-27  4:11                   ` Jeff C
  3 siblings, 2 replies; 64+ messages in thread
From: Brian May @ 2005-01-26 22:14 UTC (permalink / raw)


>>>>> "Nick" == Nick Roberts <nick.roberts@acm.org> writes:

    Nick> When I suggested that I wanted to make changes to the code,
    Nick> he indicated that those changes could not be merged back
    Nick> into the AdaCore CVS copy unless I signed a copyright
    Nick> assignment, in favour of either AdaCore or the FSF, to the
    Nick> latter of which I am agreeable.

This is standard practise for GNU software too.

In the past this type of requirement has been very controversial, and
for example resulted in emacs being split up into emacs and xemacs
(not sure what the current status is of this issue is).
  
    Nick> When I suggested that XML/Ada be moved to SourceForge, he
    Nick> indicated that it would have to be a separate project (a
    Nick> fork), whose changes could never, in practice, be merged
    Nick> back into the AdaCore CVS, because of the difficulty of
    Nick> getting all the contributors to sign the assignment. This is
    Nick> to the best of my recollection and understanding.

The implication here is if you move the project to sourceforge, you
can't control who contributes changes to the code.

This is not true, even if you place a CVS repository on sourceforge
(optional step) you can still control who has write access, and make
sure the only people who have write access have signed the agreement.
-- 
Brian May <bam@snoopy.apana.org.au>



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 16:16                 ` Nick Roberts
  2005-01-26 16:46                   ` Georg Bauhaus
  2005-01-26 22:14                   ` Brian May
@ 2005-01-26 23:48                   ` Stephen Leake
  2005-01-27 20:05                     ` Nick Roberts
  2005-01-27  4:11                   ` Jeff C
  3 siblings, 1 reply; 64+ messages in thread
From: Stephen Leake @ 2005-01-26 23:48 UTC (permalink / raw)
  To: comp.lang.ada

Nick Roberts <nick.roberts@acm.org> writes:

> My comments are based on an e-mail exchange I had with the AdaCore employee
> who was (at the time) in charge of work on XML/Ada, a couple of months ago.
> His comments came as a surprise to me, in part because of what is said on
> the web site ("Contributions to this library are most appreciated, including
> bug reports"), but I have it from the horse's mouth, so to speak.
> 
> When I suggested that I wanted to make changes to the code, he indicated
> that those changes could not be merged back into the AdaCore CVS copy unless
> I signed a copyright assignment, in favour of either AdaCore or the FSF, to
> the latter of which I am agreeable. 

ok, no problem here.

> When I suggested that XML/Ada be moved to SourceForge, he indicated
> that it would have to be a separate project (a fork), whose changes
> could never, in practice, be merged back into the AdaCore CVS,
> because of the difficulty of getting all the contributors to sign
> the assignment. This is to the best of my recollection and
> understanding.

Ok, AdaCore wants to maintain the CVS repository on their server.
That's reasonable, it's one of their supported products.

> So, I could see very little advantage to making any contributions to
> XML/Ada, since it would create two XML/Adas (mine and AdaCore's).
> Would that be an advantage to the Ada community?

Big disconnect. Why do you say there would be two? Hmm, apparently you
feel you can only contribute if the CVS repository is on SourceForge.
Why is that, specifically?

Perhaps you don't have CVS write access to AdaCore's repository?
Others have hinted that is the case, but you have not specifically
mentioned it. If that is the problem, ask them for write access, and
see what they say.

> On the subject of comments, I suggested that the amount of
> maintenance documention (in the form of comments or in any other
> form) was insufficient -- it was nearly nonexistent, in fact -- and
> the answer was, in essence, that no maintenance documentation is
> required, since the code is self-documenting. I'm afraid, to me,
> that attitude is unacceptable (and doesn't seem very professional,
> frankly).

Well, did you try reading the code? THat is the only thing that
matters, not some arbitrary standard of "not enough comment lines". If
you can, in fact, understand it, then it _is_ self-documenting.

On the other hand, I agree that a lot of AdaCore's code is not well
enough documented; I'm thinking of some parts of GtkAda in particular.

But the proper response is to contribute good documentation, not just
complain. 

-- 
-- Stephe




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 14:12               ` Marc A. Criley
@ 2005-01-27  3:59                 ` Steve
  2005-01-27  9:32                   ` Martin Krischik
  0 siblings, 1 reply; 64+ messages in thread
From: Steve @ 2005-01-27  3:59 UTC (permalink / raw)


Your experience differs from mine.

I contributed a critical bug fix and an enhancement to XML/Ada which took 
several months to appear in a public release.  Those changes were included 
in version 1.0.  How log have we been stuck on version 1.0 now?

Unless AdaCore is more responsive to integrating patches, I think it does 
merit maintaining a separate CVS tree (sourceforge or elsewhere).

Steve
(The Duck)


"Marc A. Criley" <mcNOSPAM@mckae.com> wrote in message 
news:35pmqtF4iqgimU1@individual.net...
> Nick Roberts wrote:
>>
>> My understanding is that, although XML/Ada is released under the GPL, any
>> changes I made (or anyone not an AdaCore employee) would not be merged 
>> back
>> into the AdaCore branch (because that would contaminate the copyright 
>> purity
>> of their code, apparently). If I were to develop a copy of XML/Ada (on
>> SourceForge, say), it would be a permanent fork.
>
> Well, from personal experience I can attest (and others in this thread 
> have done likewise) that XML/Ada bugs I've reported have been accepted by 
> AdaCore and been fixed in the code base.
>
> (I've also submitted patches for GtkAda's Glade and those have gone right 
> in as well.)
>
> Contributions to GNAT itself might need to undergo a more rigorous review 
> process before getging in, since that's AdaCore's family jewels, but 
> there's ample experience with most of the other AdaCore products (GtkAda, 
> GPS, ASIS-for-GNAT, and XML/Ada) demonstraing that AdaCore developers 
> readily accept bug reports and patches, take them seriously, and 
> incorporate them into the products.
>
> Marc 





^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 16:16                 ` Nick Roberts
                                     ` (2 preceding siblings ...)
  2005-01-26 23:48                   ` Stephen Leake
@ 2005-01-27  4:11                   ` Jeff C
  2005-01-27 19:05                     ` Pascal Obry
  2005-01-27 20:15                     ` Nick Roberts
  3 siblings, 2 replies; 64+ messages in thread
From: Jeff C @ 2005-01-27  4:11 UTC (permalink / raw)



"Nick Roberts" <nick.roberts@acm.org> wrote in message 
news:gemini.iaxmj2001ydde00mw.nick.roberts@acm.org...

>
> So, I could see very little advantage to making any contributions to
> XML/Ada, since it would create two XML/Adas (mine and AdaCore's). Would 
> that
> be an advantage to the Ada community?
>

Ok..Forks are bad...but is it really "better" to create a separate XML/Ada 
thing that just starts over rather than
forking all together? I suppose that is true if you have fundemental 
problems with the existing approach....

But I guess I don't see the downside to a public fork v.s. a public re-write 
of the whole thing from scratch.


My guess is ACT is just afraid to deal too closely with you because once you 
finish your OS and new Ada compiler you will be a major competitor to them.






^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 22:14                   ` Brian May
@ 2005-01-27  9:28                     ` Martin Krischik
  2005-01-27 19:55                     ` Nick Roberts
  1 sibling, 0 replies; 64+ messages in thread
From: Martin Krischik @ 2005-01-27  9:28 UTC (permalink / raw)


Brian May wrote:

> The implication here is if you move the project to sourceforge, you
> can't control who contributes changes to the code.
> 
> This is not true, even if you place a CVS repository on sourceforge
> (optional step) you can still control who has write access, and make
> sure the only people who have write access have signed the agreement.

Well I would apply (allready got some patches) and would sign as well.

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27  3:59                 ` Steve
@ 2005-01-27  9:32                   ` Martin Krischik
  2005-01-27 19:27                     ` Pascal Obry
  0 siblings, 1 reply; 64+ messages in thread
From: Martin Krischik @ 2005-01-27  9:32 UTC (permalink / raw)


Steve wrote:

> Your experience differs from mine.
> 
> I contributed a critical bug fix and an enhancement to XML/Ada which took
> several months to appear in a public release.  Those changes were included
> in version 1.0.  How log have we been stuck on version 1.0 now?
> 
> Unless AdaCore is more responsive to integrating patches, I think it does
> merit maintaining a separate CVS tree (sourceforge or elsewhere).

I guess that is true for any AdaCore project you can't get via

:pserver:anoncvs@libre.act-europe.fr:/anoncvs
(AWS , gdb-5.3, gdb-6.0, gdb-6.3,  GLADE,  gps,  GtkAda,  polyorb)

And as for forks: cvs import is quite powerfull in that respect. I think a
seperate brach would be mantainable if changes consist mostly of additional
packages and litte patches.

Up until now I only needed to patch one line of XML/Ada for my extensions.

So I would be in for a XML/Ada extension pack hostet at i.E. SourceForge.

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27  4:11                   ` Jeff C
@ 2005-01-27 19:05                     ` Pascal Obry
  2005-01-27 20:15                     ` Nick Roberts
  1 sibling, 0 replies; 64+ messages in thread
From: Pascal Obry @ 2005-01-27 19:05 UTC (permalink / raw)



"Jeff C" <jcreem@yahoo.com> writes:

> My guess is ACT is just afraid to deal too closely with you because once you 
> finish your OS and new Ada compiler you will be a major competitor to them.

ROTFL :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27  9:32                   ` Martin Krischik
@ 2005-01-27 19:27                     ` Pascal Obry
  2005-01-28  3:17                       ` Steve
                                         ` (2 more replies)
  0 siblings, 3 replies; 64+ messages in thread
From: Pascal Obry @ 2005-01-27 19:27 UTC (permalink / raw)



Martin Krischik <martin@krischik.com> writes:

> Up until now I only needed to patch one line of XML/Ada for my extensions.

So please contribute that patch or tell us more why it was rejected.

> So I would be in for a XML/Ada extension pack hostet at i.E. SourceForge.

That's a very bad idea to me. Better to have one strong Ada tools that
zillions of not-well-supported forked ones. It is fine to have another
project to build an XML parser in Ada but for me a fork is really bad and
should happen only if there is *big* maintenance problem.

One good point on the Ada side is the strong standard. We really want to
build on this. Not a lot of libraries but some good, well documented, safe
ones that does the job.

Personally I would not like to find an AWS fork. I've tried (and will
continue to) to work with the contributors to have patches integrated.
But it is true that patches are not always very easy to integrate and
requires some changes.

Note that I know well the main XML/Ada maintainer and can tell you that if
a patch is not integrated yet there is certainly good reasons.

Another note. In this thread one guy (can't remember who sorry) talked about
CVS write access. This is not serious. To have a write access to a project you
really want to become part of the project team, take responsibilities for part
of it... and of course you can't keep the copyright, this would be a problem
for the product in the long term.

Anyway, just my 2 cents ;)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 16:46                   ` Georg Bauhaus
@ 2005-01-27 19:45                     ` Nick Roberts
  0 siblings, 0 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-27 19:45 UTC (permalink / raw)


Georg Bauhaus <bauhaus@futureapps.de> wrote:

> Looking at the code, there are lots and lots of comments, mostly in the
> specs, but also in some bodies. I have also found the introductory
> sections in some of the specs instructive, if somewhat formal. What is it
> that is missing when you want to "maintain" XML/Ada?

There are almost no comments in the package bodies, and there is no other
maintenance documentation in any other form. To my mind, that's ridiculous
for such a complex piece of software.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 22:14                   ` Brian May
  2005-01-27  9:28                     ` Martin Krischik
@ 2005-01-27 19:55                     ` Nick Roberts
  2005-01-28 10:05                       ` Stephen Leake
  1 sibling, 1 reply; 64+ messages in thread
From: Nick Roberts @ 2005-01-27 19:55 UTC (permalink / raw)


Brian May <bam@snoopy.apana.org.au> wrote:

> ...
> The implication here is if you move the project to sourceforge, you can't
> control who contributes changes to the code.
> 
> This is not true, even if you place a CVS repository on sourceforge
> (optional step) you can still control who has write access, and make sure
> the only people who have write access have signed the agreement.

I am merely reporting what was my understanding of what the AdaCore employee
was telling me. He warned me that it might be impractical (even if
theoretically possible) to obtain the necessary signed agreement from all
contributors to a SourceForge project. (Again, I hope I'm recalling the gist
of the exchange correctly.)

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-26 23:48                   ` Stephen Leake
@ 2005-01-27 20:05                     ` Nick Roberts
  2005-01-27 20:57                       ` Marc A. Criley
  2005-01-28 10:17                       ` Stephen Leake
  0 siblings, 2 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-27 20:05 UTC (permalink / raw)


Stephen Leake <stephen_leake@acm.org> wrote:

> > So, I could see very little advantage to making any contributions to
> > XML/Ada, since it would create two XML/Adas (mine and AdaCore's). Would
> > that be an advantage to the Ada community?
> 
> Big disconnect. Why do you say there would be two? Hmm, apparently you
> feel you can only contribute if the CVS repository is on SourceForge. Why
> is that, specifically?

I told the AdaCore employee that I wanted to make a large number of small
changes (a lot of comments that would help identify fragments of code, for
referential maintenance documentation), and he responded that he felt such
changes were not necessary. I took this to imply (although admittedly he
didn't say so explicitly) that he wouldn't accept these changes into the
AdaCore CVS repository. On this basis, I was assuming that I would have to
create a forked project on some other repository (of course it doesn't have
to be SourceForge per se).

> > On the subject of comments, I suggested that the amount of maintenance
> > documention (in the form of comments or in any other form) was
> > insufficient -- it was nearly nonexistent, in fact -- and the answer
> > was, in essence, that no maintenance documentation is required, since
> > the code is self-documenting. I'm afraid, to me, that attitude is
> > unacceptable (and doesn't seem very professional, frankly).
> 
> Well, did you try reading the code? THat is the only thing that matters,
> not some arbitrary standard of "not enough comment lines". If you can, in
> fact, understand it, then it _is_ self-documenting.

Of course I read the code, Stephen!  In the package bodies there are almost
no comments at all, and there is no other maintenance documentation. The
code is very complex, and no vaguely self-documenting. The idea that it
could be struck me (and still strikes me) as, frankly, bizarre.

> On the other hand, I agree that a lot of AdaCore's code is not well enough
> documented; I'm thinking of some parts of GtkAda in particular.

Well, that would seem to be a case in point, then.

> But the proper response is to contribute good documentation, not just
> complain.

I wanted to do precisely that!  I specifically offered to contribute
maintenance documentation, but this offer seemed to be rejected, in effect,
by the AdaCore employee I communicated with.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27  4:11                   ` Jeff C
  2005-01-27 19:05                     ` Pascal Obry
@ 2005-01-27 20:15                     ` Nick Roberts
  2005-01-27 22:28                       ` Pascal Obry
  1 sibling, 1 reply; 64+ messages in thread
From: Nick Roberts @ 2005-01-27 20:15 UTC (permalink / raw)


"Jeff C" <jcreem@yahoo.com> wrote:

> Ok..Forks are bad...but is it really "better" to create a separate XML/Ada
> thing that just starts over rather than forking all together? I suppose
> that is true if you have fundemental problems with the existing
> approach....

I don't have any fundamental problems with the approach taken by XML/Ada,
except that it doesn't have any maintenance documentation, and AdaCore don't
seem to think any is necessary (isn't that weird?).

But the DOM interface is not very suited to Ada, and neither is the SAX
interface. There are lots of little technical niggles. One of the problems
with XML/Ada 1.0 is that it doesn't support (read?) DTDs. For my own use,
although I don't need validation, I do need to be able to declare entities
in the DTD that will be correctly expanded in the document (I think this has
significance for default attribute values).

> But I guess I don't see the downside to a public fork v.s. a public
> re-write of the whole thing from scratch.

It's a question that I contemplated quite a lot myself. I agree that the
answer isn't obvious.

> My guess is ACT is just afraid to deal too closely with you because once
> you finish your OS and new Ada compiler you will be a major competitor to
> them.

I guess that's a joke, but I don't see how AdaOS or ECLAT could be
competition for AdaCore. Quite the opposite, since both will be released
under the GPL, there would be absolutely nothing stopping AdaCore (or anyone
else) from selling support for either or both, just as they sell support now
for GNAT and other GPL software. They /should/ see AdaOS and ECLAT as a
commercial opportunity.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 20:05                     ` Nick Roberts
@ 2005-01-27 20:57                       ` Marc A. Criley
  2005-01-27 22:11                         ` Nick Roberts
  2005-01-28 10:17                       ` Stephen Leake
  1 sibling, 1 reply; 64+ messages in thread
From: Marc A. Criley @ 2005-01-27 20:57 UTC (permalink / raw)


Nick Roberts wrote:
> 
> I told the AdaCore employee that I wanted to make a large number of small
> changes (a lot of comments that would help identify fragments of code, for
> referential maintenance documentation), and he responded that he felt such
> changes were not necessary. I took this to imply (although admittedly he
> didn't say so explicitly) that he wouldn't accept these changes into the
> AdaCore CVS repository. On this basis, I was assuming that I would have to
> create a forked project on some other repository (of course it doesn't have
> to be SourceForge per se).

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.

IMHO, modifying files just to fix and add comments has risk.  Small, 
certainly, but it's not zero.  And if you're talking about modifying 
lots of files to do this, that risk is there for each file.

I would certainly love to see commenting improve, but I have to weigh 
that against the small risk of something that works just fine getting 
accidentally broken, i.e., "if it ain't broke, don't fix it".  And for 
me, barring some externally imposed coding/commenting standard, I come 
down just barely on the side of leaving it alone.

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.

Marc



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 20:57                       ` Marc A. Criley
@ 2005-01-27 22:11                         ` Nick Roberts
  2005-01-27 22:24                           ` Pascal Obry
                                             ` (5 more replies)
  0 siblings, 6 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-27 22:11 UTC (permalink / raw)


"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



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:11                         ` Nick Roberts
@ 2005-01-27 22:24                           ` Pascal Obry
  2005-01-28  0:29                             ` Nick Roberts
  2005-01-28  2:56                           ` Steve
                                             ` (4 subsequent siblings)
  5 siblings, 1 reply; 64+ messages in thread
From: Pascal Obry @ 2005-01-27 22:24 UTC (permalink / raw)



Nick Roberts <nick.roberts@acm.org> writes:

> 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).

Ok, I see. I understand better why it was rejected. You are proposing to
change the way the software is done. For sure I would also reject such a
change in AWS. I just don't like tags in the code. That's of course just a
matter of taste.

> The issue is whether I should:
> 
>    (a) create a fork of Ada/XML and develop it;

I would say no. But I think it is clear after reading my other message :)

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

Why not.

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

Why not.

> 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.

And you will probably fit the AdaOS development somewhere too, and ECLAT,
and... what is your other plans for the next 200 years ????

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 20:15                     ` Nick Roberts
@ 2005-01-27 22:28                       ` Pascal Obry
  2005-01-28  0:30                         ` Nick Roberts
  0 siblings, 1 reply; 64+ messages in thread
From: Pascal Obry @ 2005-01-27 22:28 UTC (permalink / raw)



Nick Roberts <nick.roberts@acm.org> writes:

> I don't have any fundamental problems with the approach taken by XML/Ada,
> except that it doesn't have any maintenance documentation, and AdaCore don't
> seem to think any is necessary (isn't that weird?).

I did not read your previous message this way. It was rejected because of the
proposed style not because it was felt not necessary!

> But the DOM interface is not very suited to Ada, and neither is the SAX
> interface. 

That's a common standard interface. Are we going to try to do better and break
the SAX/DOM well known interface ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:24                           ` Pascal Obry
@ 2005-01-28  0:29                             ` Nick Roberts
  2005-01-28  7:22                               ` Pascal Obry
  0 siblings, 1 reply; 64+ messages in thread
From: Nick Roberts @ 2005-01-28  0:29 UTC (permalink / raw)


Pascal Obry <pascal@obry.org> wrote:

> ...
> And you will probably fit the AdaOS development somewhere too, and ECLAT,
> and... what is your other plans for the next 200 years ????

If I develop my own XML package, it will take priority over the other
things. I would then use it to develop my literate programming 'reverse
tangle' program, which I need for processing the documentation of ECLAT and
AdaOS anyway.

And if medical science keeps moving on, I may live for 200 years. But if I
don't, Pascal, at least when I die I will do so knowing that I tried to
achieve something big, rather than just sitting on the side scoffing at
other people's efforts.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:28                       ` Pascal Obry
@ 2005-01-28  0:30                         ` Nick Roberts
  0 siblings, 0 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-28  0:30 UTC (permalink / raw)


Pascal Obry <pascal@obry.org> wrote:

> > I don't have any fundamental problems with the approach taken by
> > XML/Ada, except that it doesn't have any maintenance documentation, and
> > AdaCore don't seem to think any is necessary (isn't that weird?).
> 
> I did not read your previous message this way. It was rejected because of
> the proposed style not because it was felt not necessary!

My offer of adding maintenance documentation was apparently rejected because
it was felt not to be necessary. That is more or less what I said in my
previous message.

> > But the DOM interface is not very suited to Ada, and neither is the SAX
> > interface.
> 
> That's a common standard interface. Are we going to try to do better and
> break the SAX/DOM well known interface ?

If I were to write a package with a different interface, it would be adding
to the choice between SAX and DOM (use XML/Ada) and something else. It
wouldn't be breaking the well-known interfaces in any event, and if it was
better, then it would be better!

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:11                         ` Nick Roberts
  2005-01-27 22:24                           ` Pascal Obry
@ 2005-01-28  2:56                           ` Steve
  2005-01-28 13:32                             ` Georg Bauhaus
  2005-01-28 15:25                             ` Nick Roberts
  2005-01-28 10:23                           ` Stephen Leake
                                             ` (3 subsequent siblings)
  5 siblings, 2 replies; 64+ messages in thread
From: Steve @ 2005-01-28  2:56 UTC (permalink / raw)


Actually XML/Ada does support validation, I'm using it.

    Set_Feature( tree_reader, Validation_Feature, TRUE);

I don't know whether or not the implementation is buggy, but I do know that 
it has worked in the cases I have tested.

Steve
(The Duck)


"Nick Roberts" <nick.roberts@acm.org> wrote in message 
news:gemini.iazxmw00jrr0d008g.nick.roberts@acm.org...
[snip]
>
> 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 





^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 19:27                     ` Pascal Obry
@ 2005-01-28  3:17                       ` Steve
  2005-01-28  7:14                         ` Pascal Obry
  2005-01-28 10:00                         ` Stephen Leake
  2005-01-28  7:47                       ` Martin Krischik
  2005-01-28  9:57                       ` Stephen Leake
  2 siblings, 2 replies; 64+ messages in thread
From: Steve @ 2005-01-28  3:17 UTC (permalink / raw)


Personally I would prefer to see an XML/Ada tree at SourceForge.

I have been following the GCC mailing lists for some time.  Remember that 
even though GNAT is part of the GCC family of languages, AdaCore maintains 
their own internal tree independent of the GCC tree.

AdaCore has a commitment to maintain a stable base of software for their 
customers.  It would be difficult for them to use the GCC tree directly.  It 
would also be unresonable to require patches to the GCC to be reviewed by 
AdaCore, thus there is a need to maintain two repositories.  Thankfully 
AdaCore dedicates resources to keep the two trees in sync, which is mutually 
beneficial.

If the libre site granted read access to the XML/Ada CVS and a reasonable 
response time in reviewing and applying patches to an XML/Ada, I would see 
no need to maintain a separate repository.  I cannot however see any 
financial advantage for them to do so, and doubt they will.

So in my opinion if XML/Ada is to grow outside of AdaCore, a separate 
repository is warranted.

For obvious reasons, I think it is best that a single repository outside of 
AdaCore be used for a more open development.  Preferably some convention of 
peer review prior to integrating changes will be included in maintaining the 
repository.

Steve
(The Duck)






^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28  3:17                       ` Steve
@ 2005-01-28  7:14                         ` Pascal Obry
  2005-01-28 10:00                         ` Stephen Leake
  1 sibling, 0 replies; 64+ messages in thread
From: Pascal Obry @ 2005-01-28  7:14 UTC (permalink / raw)



"Steve" <nospam_steved94@comcast.net> writes:

> If the libre site granted read access to the XML/Ada CVS and a reasonable 
> response time in reviewing and applying patches to an XML/Ada, I would see 
> no need to maintain a separate repository.  I cannot however see any 
> financial advantage for them to do so, and doubt they will.

Did you ask for a CVS tree at Libre site ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28  0:29                             ` Nick Roberts
@ 2005-01-28  7:22                               ` Pascal Obry
  0 siblings, 0 replies; 64+ messages in thread
From: Pascal Obry @ 2005-01-28  7:22 UTC (permalink / raw)



Nick Roberts <nick.roberts@acm.org> writes:

> And if medical science keeps moving on, I may live for 200 years. But if I
> don't, Pascal, at least when I die I will do so knowing that I tried to
> achieve something big, rather than just sitting on the side scoffing at
> other people's efforts.

Nick, I'm not scoffing. As an Ada contributor I do appreciate all your
efforts and I also pretty well know what is the level of implication needed
to do something professional. But frankly it seems that you are targetting
something that will be very hard (impossible?) to achieve. You have too many
thing in your plate. The Ada community is small and you'll need lot of
contributions to achieve your goals: ECLAT and Ada compiler, AdaOS, and XML
parser with validation based on DTD/schema, ... !

Again, I'm not scoffing and wish you good luck.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 19:27                     ` Pascal Obry
  2005-01-28  3:17                       ` Steve
@ 2005-01-28  7:47                       ` Martin Krischik
  2005-01-28  9:57                       ` Stephen Leake
  2 siblings, 0 replies; 64+ messages in thread
From: Martin Krischik @ 2005-01-28  7:47 UTC (permalink / raw)


Pascal Obry wrote:

> 
> Martin Krischik <martin@krischik.com> writes:
> 
>> Up until now I only needed to patch one line of XML/Ada for my
>> extensions.
> 
> So please contribute that patch or tell us more why it was rejected.

I did contribute the patch:

diff unicode-ccs.adb /work/ada/xmlada-1.0/unicode/unicode-ccs.adb
34d33
< with Unicode.CCS.Iso_8859_15;
52,53d50
<       elsif Name = Iso_8859_15.Name1 then
<          return Iso_8859_15.Iso_8859_15_Character_Set;

and it is probably integrated. But since I have no access the the XML/Ada
cvs tree I cant confirm that. So until there is a new release I have to
keep a patched file in AdaCL as well.

>> So I would be in for a XML/Ada extension pack hostet at i.E. SourceForge.
> 
> That's a very bad idea to me. Better to have one strong Ada tools that
> zillions of not-well-supported forked ones. It is fine to have another
> project to build an XML parser in Ada but for me a fork is really bad and
> should happen only if there is *big* maintenance problem.

Fine.

> One good point on the Ada side is the strong standard. We really want to
> build on this. Not a lot of libraries but some good, well documented, safe
> ones that does the job.

Shure.

> Note that I know well the main XML/Ada maintainer and can tell you that if
> a patch is not integrated yet there is certainly good reasons.

The problem is not the integration but the long puplic release cycles. I
well understand that public relases does cost money and bring only
marketing value and I fully understand AdaCore here.

Read only cvs access would help.
 
> Another note. In this thread one guy (can't remember who sorry) talked
> about CVS write access. This is not serious. To have a write access to a
> project you really want to become part of the project team, take
> responsibilities for part of it... and of course you can't keep the
> copyright, this would be a problem for the product in the long term.

But that indicates: It is not impossible if you are realy commited to
extened one AdaCore maintained product and you can show that your
extensions are worthy.

(I don't have anything im mind right now - just like to know on basic
principle)

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 19:27                     ` Pascal Obry
  2005-01-28  3:17                       ` Steve
  2005-01-28  7:47                       ` Martin Krischik
@ 2005-01-28  9:57                       ` Stephen Leake
  2005-01-28 16:36                         ` Pascal Obry
  2 siblings, 1 reply; 64+ messages in thread
From: Stephen Leake @ 2005-01-28  9:57 UTC (permalink / raw)
  To: comp.lang.ada

Pascal Obry <pascal@obry.org> writes:

> Martin Krischik <martin@krischik.com> writes:
> 
> > So I would be in for a XML/Ada extension pack hostet at i.E. SourceForge.
> 
> That's a very bad idea to me. 

Some of us agree, but you have not addressed the issue that, for
XML/Ada at least, contributions are not available in a timely way.

> Better to have one strong Ada tools that zillions of
> not-well-supported forked ones. It is fine to have another project
> to build an XML parser in Ada but for me a fork is really bad and
> should happen only if there is *big* maintenance problem.

Waiting a year for a contribution to be generally available counts as
a "big" problem for me.

> One good point on the Ada side is the strong standard. We really
> want to build on this. Not a lot of libraries but some good, well
> documented, safe ones that does the job.

We all agree with that.

> Personally I would not like to find an AWS fork. I've tried (and
> will continue to) to work with the contributors to have patches
> integrated. But it is true that patches are not always very easy to
> integrate and requires some changes.

We all agree with that as well.

> Note that I know well the main XML/Ada maintainer and can tell you
> that if a patch is not integrated yet there is certainly good
> reasons.

The issue is, after a patch is integrated, how long is it before it is
available to others?

> Another note. In this thread one guy (can't remember who sorry) talked about
> CVS write access. 

That was me; it appeared to be an issue for Nick Roberts.

> This is not serious. 

I'm not clear what you mean here; I was certainly "serious".

> To have a write access to a project you really want to become part
> of the project team, take responsibilities for part of it... and of
> course you can't keep the copyright, this would be a problem for the
> product in the long term.

Ok, so you mean "it is not reasonable to grant write access to
everyone who makes a contribution". That's fine. 

However, it is necessary for _everyone_ to have read access to a CVS
repository, if you want to encourage comtributions to that repository.

-- 
-- Stephe




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28  3:17                       ` Steve
  2005-01-28  7:14                         ` Pascal Obry
@ 2005-01-28 10:00                         ` Stephen Leake
  1 sibling, 0 replies; 64+ messages in thread
From: Stephen Leake @ 2005-01-28 10:00 UTC (permalink / raw)
  To: comp.lang.ada

"Steve" <nospam_steved94@comcast.net> writes:

> If the libre site granted read access to the XML/Ada CVS and a reasonable 
> response time in reviewing and applying patches to an XML/Ada, I would see 
> no need to maintain a separate repository.  I cannot however see any 
> financial advantage for them to do so, and doubt they will.

Let's make sure we've asked AdaCore, and confirmed that they won't do
this, before starting a SourceForge branch. Pascal seems to be
implying that AdaCore might put a readable CVS tree at the Libre site.

> So in my opinion if XML/Ada is to grow outside of AdaCore, a
> separate repository is warranted.

If AdaCore does not create a readable XML/Ada tree, then I agree with
you; a SourceForge branch of XML/Ada makes sense.

-- 
-- Stephe




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 19:55                     ` Nick Roberts
@ 2005-01-28 10:05                       ` Stephen Leake
  0 siblings, 0 replies; 64+ messages in thread
From: Stephen Leake @ 2005-01-28 10:05 UTC (permalink / raw)
  To: comp.lang.ada

Nick Roberts <nick.roberts@acm.org> writes:

> Brian May <bam@snoopy.apana.org.au> wrote:
> 
> > ...
> > The implication here is if you move the project to sourceforge, you can't
> > control who contributes changes to the code.
> > 
> > This is not true, even if you place a CVS repository on sourceforge
> > (optional step) you can still control who has write access, and make sure
> > the only people who have write access have signed the agreement.
> 
> I am merely reporting what was my understanding of what the AdaCore employee
> was telling me. He warned me that it might be impractical (even if
> theoretically possible) to obtain the necessary signed agreement from all
> contributors to a SourceForge project. (Again, I hope I'm recalling the gist
> of the exchange correctly.)

The problem of getting proper signed agreements is not limited to
SourceForge projects. I suspect the AdaCore employee was just
reflecting that it is a problem in general, and one AdaCore does not
want to have to deal with.

-- 
-- Stephe




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 20:05                     ` Nick Roberts
  2005-01-27 20:57                       ` Marc A. Criley
@ 2005-01-28 10:17                       ` Stephen Leake
  1 sibling, 0 replies; 64+ messages in thread
From: Stephen Leake @ 2005-01-28 10:17 UTC (permalink / raw)
  To: comp.lang.ada

Nick Roberts <nick.roberts@acm.org> writes:

> Stephen Leake <stephen_leake@acm.org> wrote:
> 
> > > So, I could see very little advantage to making any contributions to
> > > XML/Ada, since it would create two XML/Adas (mine and AdaCore's). Would
> > > that be an advantage to the Ada community?
> > 
> > Big disconnect. Why do you say there would be two? Hmm, apparently you
> > feel you can only contribute if the CVS repository is on SourceForge. Why
> > is that, specifically?
> 
> I told the AdaCore employee that I wanted to make a large number of small
> changes (a lot of comments that would help identify fragments of code, for
> referential maintenance documentation), and he responded that he felt such
> changes were not necessary. I took this to imply (although admittedly he
> didn't say so explicitly) that he wouldn't accept these changes into the
> AdaCore CVS repository. On this basis, I was assuming that I would have to
> create a forked project on some other repository (of course it doesn't have
> to be SourceForge per se).

Ok. So, you could not contribute your particular changes because the
"project architect" did not agree they are necessary.

This is a fact of life when more than one person is on a project.
Somebody has to be the architect (I don't think the "bazaar" model is
appropriate), and everyone else has to agree to live with the
architects rules.

If the architect is a good project manager, they will listen to the
developers, and adjust the rules to maintain a healthy project.

In your particular case, I don't know enough to say whether I would
lobby for what you wanted to do. The statements you have made here
have not had detail; they have just been of the form "the number of
comment lines is too small". I would reject such justifications as
well.

> > > On the subject of comments, I suggested that the amount of
> > > maintenance documention (in the form of comments or in any other
> > > form) was insufficient -- it was nearly nonexistent, in fact --
> > > and the answer was, in essence, that no maintenance
> > > documentation is required, since the code is self-documenting.
> > > I'm afraid, to me, that attitude is unacceptable (and doesn't
> > > seem very professional, frankly).
> > 
> > Well, did you try reading the code? THat is the only thing that matters,
> > not some arbitrary standard of "not enough comment lines". If you can, in
> > fact, understand it, then it _is_ self-documenting.
> 
> Of course I read the code, Stephen!  In the package bodies there are almost
> no comments at all, and there is no other maintenance documentation. The
> code is very complex, and no vaguely self-documenting. 

I guess you are saying "I did not understand the code, and comments
would help".

> The idea that it could be struck me (and still strikes me) as,
> frankly, bizarre.

It's not bizarre to me; it is something I strive for. Because the Ada
compiler checks the code, but it does not check the comments. I
believe Tucker Taft expressed simmilar sentiments at a SigAda several
years ago (something like "good Ada code doesn't need comments").

Again, that's a fact of life when more than one person is on a
project; people will have different opinions about the appropriate
level of code comments.

I often find myself wishing for an introduction to a complex set of
code. But once I figure out the basic structure, I would find such an
introduction annoying, because it would necessarily be inaccurate.
So I would lobby for creating such an introduction in a separate
document, not as code comments.

> > On the other hand, I agree that a lot of AdaCore's code is not
> > well enough documented; I'm thinking of some parts of GtkAda in
> > particular.
> 
> Well, that would seem to be a case in point, then.
> 
> > But the proper response is to contribute good documentation, not just
> > complain.
> 
> I wanted to do precisely that!  I specifically offered to contribute
> maintenance documentation, but this offer seemed to be rejected, in effect,
> by the AdaCore employee I communicated with.

Ok. It is a problem. But not, I think, a sufficient problem to warrant
a fork.

Perhaps if you offered to write a separate introduction document, that
would be accepted.

-- 
-- Stephe




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:11                         ` Nick Roberts
  2005-01-27 22:24                           ` Pascal Obry
  2005-01-28  2:56                           ` Steve
@ 2005-01-28 10:23                           ` Stephen Leake
  2005-01-29 11:58                             ` Simon Wright
  2005-01-28 13:47                           ` Georg Bauhaus
                                             ` (2 subsequent siblings)
  5 siblings, 1 reply; 64+ messages in thread
From: Stephen Leake @ 2005-01-28 10:23 UTC (permalink / raw)
  To: comp.lang.ada

Nick Roberts <nick.roberts@acm.org> writes:

> 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.

Ok, I agree with you stongly here!

> 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.

You left out:

(d) create a separate repository of documentation for XML/Ada

This option satisfies most of your immediate goal. It does not have
the links from the code to the documentation, but that can be handled
in other ways (admittedly not as nice).

> 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)

Ok. Did AdaCore comment on the usefulness of this functionality? That
is, would they view it as a valuable contribution, worth their time to
integrate?


> -- and it has no maintenance documentation.

Which is not a show stopper, just a problem, which can be solved even
without AdaCore's cooperation.

-- 
-- Stephe




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28  2:56                           ` Steve
@ 2005-01-28 13:32                             ` Georg Bauhaus
  2005-01-28 15:25                             ` Nick Roberts
  1 sibling, 0 replies; 64+ messages in thread
From: Georg Bauhaus @ 2005-01-28 13:32 UTC (permalink / raw)


Steve wrote:
> Actually XML/Ada does support validation, I'm using it.
> 
>     Set_Feature( tree_reader, Validation_Feature, TRUE);
> 
> I don't know whether or not the implementation is buggy, but I do know that 
> it has worked in the cases I have tested.

It's not a validating parser in the sense of XMLthough.
Denny Vrandečić explains why, in the docs about XML4Ada95.

In Get_Feature in XML/Ada,

       elsif Name = Parameter_Entities_Feature then
          return False;  --  ??? Unsupported for now
       end if;


-- georg



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:11                         ` Nick Roberts
                                             ` (2 preceding siblings ...)
  2005-01-28 10:23                           ` Stephen Leake
@ 2005-01-28 13:47                           ` Georg Bauhaus
  2005-01-29 17:08                             ` Nick Roberts
  2005-01-28 13:54                           ` Georg Bauhaus
  2005-01-29 11:54                           ` Simon Wright
  5 siblings, 1 reply; 64+ messages in thread
From: Georg Bauhaus @ 2005-01-28 13:47 UTC (permalink / raw)


Nick Roberts wrote:

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

I vaguely remember a discussion of literate programming a few years
ago. One argument was that practical systems weren't present.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:11                         ` Nick Roberts
                                             ` (3 preceding siblings ...)
  2005-01-28 13:47                           ` Georg Bauhaus
@ 2005-01-28 13:54                           ` Georg Bauhaus
  2005-01-29 11:54                           ` Simon Wright
  5 siblings, 0 replies; 64+ messages in thread
From: Georg Bauhaus @ 2005-01-28 13:54 UTC (permalink / raw)


Nick Roberts wrote:

> 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.

What is missing - for the learner - is "An Introduction to the
Implementation". Maybe. Though for your comfort, have a look
at the sources of SP, which is heavily used in "SGML industries".

$ apt-get source sp

or, alternatively,

http://www.jclark.com/sp/howtoget.htm

-- Georg



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28  2:56                           ` Steve
  2005-01-28 13:32                             ` Georg Bauhaus
@ 2005-01-28 15:25                             ` Nick Roberts
  1 sibling, 0 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-28 15:25 UTC (permalink / raw)


"Steve" <nospam_steved94@comcast.net> wrote:

> Actually XML/Ada does support validation, I'm using it.
> 
>     Set_Feature( tree_reader, Validation_Feature, TRUE);
> 
> I don't know whether or not the implementation is buggy, but I do know
> that it has worked in the cases I have tested.

Sorry, that was a misapprehension on my part.

I've been taking another look at the DOM interface (of XML/Ada 1.0), and I
really am convinced that my own interface is significantly better (more
concise, more efficient), so I'm going to go ahead and develop it. Perhaps
what I'll do is to get it working minimally as quickly as I can, post it
somewhere public, and see if anyone likes it. It is really an alternative to
the DOM, rather than direct competition.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28  9:57                       ` Stephen Leake
@ 2005-01-28 16:36                         ` Pascal Obry
  0 siblings, 0 replies; 64+ messages in thread
From: Pascal Obry @ 2005-01-28 16:36 UTC (permalink / raw)



Stephen Leake <stephen_leake@acm.org> writes:

> However, it is necessary for _everyone_ to have read access to a CVS
> repository, if you want to encourage comtributions to that repository.

Agreed.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-27 22:11                         ` Nick Roberts
                                             ` (4 preceding siblings ...)
  2005-01-28 13:54                           ` Georg Bauhaus
@ 2005-01-29 11:54                           ` Simon Wright
  2005-01-29 16:54                             ` Nick Roberts
  5 siblings, 1 reply; 64+ messages in thread
From: Simon Wright @ 2005-01-29 11:54 UTC (permalink / raw)


Nick Roberts <nick.roberts@acm.org> writes:

> 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.

I'm not completely up to speed on this, but aren't DTDs a bit old-hat?
(of course there are many varieties of schema, I suppose
old-hat-but-standard is better than was-current-five-years-back)

-- 
Simon Wright                               100% Ada, no bugs.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28 10:23                           ` Stephen Leake
@ 2005-01-29 11:58                             ` Simon Wright
  0 siblings, 0 replies; 64+ messages in thread
From: Simon Wright @ 2005-01-29 11:58 UTC (permalink / raw)


Stephen Leake <stephen_leake@acm.org> writes:

> Nick Roberts <nick.roberts@acm.org> writes:

> > -- and it has no maintenance documentation.
> 
> Which is not a show stopper, just a problem, which can be solved even
> without AdaCore's cooperation.

_I_ would be reluctant to commit to documenting a source tree to which
I had no access, and where the committers didn't support my efforts.

-- 
Simon Wright                               100% Ada, no bugs.



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-29 11:54                           ` Simon Wright
@ 2005-01-29 16:54                             ` Nick Roberts
  0 siblings, 0 replies; 64+ messages in thread
From: Nick Roberts @ 2005-01-29 16:54 UTC (permalink / raw)


Simon Wright <simon@pushface.org> wrote:

> > 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.
> 
> I'm not completely up to speed on this, but aren't DTDs a bit old-hat? (of
> course there are many varieties of schema, I suppose old-hat-but-standard
> is better than was-current-five-years-back)

You're dead right, Simon, but OASIS uses a DTD (a whopper) for the
validation of DocBook/XML documents (see http://docbook.sourceforge.net/),
presumably because there are still more tools out there, currently, which
support DTD validation (only) rather than XML Schema validation. Perhaps
also of significance is that the DTD is used to declare appropriate default
values for various attributes and all the many DocBook character entities.

There are certain useful things that can be done by DTD (internal or
external) which, to my knowledge, cannot be done any other way. For example,
I have a need to break up a big source document into many files, and then
include them in a (logically single) DocBook document as entities.

I suspect that a lot of other people will need DTD support (if not actual
validation) for a while to come, for various reasons. It probably doesn't
hurt, if an XML processor supports DTDs at all, for it to validate. (It
/must/ also support standalone documents with no DTD!)

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-28 13:47                           ` Georg Bauhaus
@ 2005-01-29 17:08                             ` Nick Roberts
  2005-01-31 14:24                               ` Marc A. Criley
  0 siblings, 1 reply; 64+ messages in thread
From: Nick Roberts @ 2005-01-29 17:08 UTC (permalink / raw)


Georg Bauhaus <sb463ba@user1.uni-duisburg.de> wrote:

> I vaguely remember a discussion of literate programming a few years ago.
> One argument was that practical systems weren't present.

Well, practical systems certainly are present, and available freely. I think
one good source is:

   http://www.literateprogramming.com/

But most of these systems do suffer from the impracticality of requiring, in
general, a 'tangle' of the entire project in order to test any member
program after code changes have been made (however tiny) to any part of it.

Some systems do offer an 'untangle' facility, permitting changes made to the
'source' files (which are non-original in a traditional literate programming
system) to be merged back into the source document files (which are the
canonical originals). But this approach has certain dangers, and makes the
overall system very complex.

I'm developing a 'reverse tangle' tool which takes this idea to the logical
extreme of restoring the source code files back to their status as original
files (intended to be edited by humans). This means that code changes can be
made, and programs rebuilt and tested, using the traditional tool/IDE cycle
(no need for any tangling). Reverse tangling is required when formatting the
documentation, and the only literate programming tool required is the
reverse tangle tool, which is way much simpler.

-- 
Nick Roberts



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2005-01-29 17:08                             ` Nick Roberts
@ 2005-01-31 14:24                               ` Marc A. Criley
  0 siblings, 0 replies; 64+ messages in thread
From: Marc A. Criley @ 2005-01-31 14:24 UTC (permalink / raw)


Nick Roberts wrote:
> Some systems do offer an 'untangle' facility, permitting changes made to the
> 'source' files (which are non-original in a traditional literate programming
> system) to be merged back into the source document files (which are the
> canonical originals). But this approach has certain dangers, and makes the
> overall system very complex.
> 
> I'm developing a 'reverse tangle' tool which takes this idea to the logical
> extreme of restoring the source code files back to their status as original
> files (intended to be edited by humans). This means that code changes can be
> made, and programs rebuilt and tested, using the traditional tool/IDE cycle
> (no need for any tangling). Reverse tangling is required when formatting the
> documentation, and the only literate programming tool required is the
> reverse tangle tool, which is way much simpler.

I'm not as up on literate programming as I could be, but I found some 
interesting, and I believe, related material in the article "Extensible 
Programming for the 21st Century":
  (http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=247).

(The author suggests an XML representation of the "source code", so 
we're still on-topic in this thread :-)

Marc A. Criley
McKae Technologies
www.mckae.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2004-11-09  3:14 ` Steve
  2005-01-20 12:16   ` okellogg
@ 2021-11-22 13:01   ` James Hitch
  2021-11-22 13:31     ` Simon Wright
  1 sibling, 1 reply; 64+ messages in thread
From: James Hitch @ 2021-11-22 13:01 UTC (permalink / raw)


On Tuesday, 9 November 2004 at 03:14:13 UTC, Steve wrote:
> XML/Ada
> http://libre.act-europe.fr/xmlada/
> Includes a Unicode module, a SAX 2.0 module, and a DOM 2.0 module.
> The code is released under the GMGPL.
> Support is available for a fee from AdaCore.
> In addition to the platforms listed at the Libre site, I a have successfully
> used XML/Ada 1.0 with ObjectAda 7.2.2.
> Steve
> (The Duck)
> 
> "Tim Roede" <timothy...@boeing.com> wrote in message
> news:41900010...@boeing.com...
> > There is considerable interest in the group I am working with to provide
> > XML parsing using both DOM and SAX parsing. Does anyone have a name or
> > a link to a suitable Ada library (similar to xerces)?
> >
> > Please respond using email.
> >
> > Thanks in advance
> >
> > timothy...@boeing.com
I'd be very interested in compiling XML/Ada from AdaCore with ObjectAda 10.  Any clues would be very helpful.

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2021-11-22 13:01   ` James Hitch
@ 2021-11-22 13:31     ` Simon Wright
  2021-11-22 13:54       ` James Hitch
  0 siblings, 1 reply; 64+ messages in thread
From: Simon Wright @ 2021-11-22 13:31 UTC (permalink / raw)


James Hitch <jimbodeman@gmail.com> writes:

> On Tuesday, 9 November 2004 at 03:14:13 UTC, Steve wrote:

> I'd be very interested in compiling XML/Ada from AdaCore with
> ObjectAda 10.  Any clues would be very helpful.

What goes wrong when you try?

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2021-11-22 13:31     ` Simon Wright
@ 2021-11-22 13:54       ` James Hitch
  0 siblings, 0 replies; 64+ messages in thread
From: James Hitch @ 2021-11-22 13:54 UTC (permalink / raw)


On Monday, 22 November 2021 at 13:31:19 UTC, Simon Wright wrote:
> James Hitch <jimbo...@gmail.com> writes: 
> 
> > On Tuesday, 9 November 2004 at 03:14:13 UTC, Steve wrote: 
> 
> > I'd be very interested in compiling XML/Ada from AdaCore with 
> > ObjectAda 10. Any clues would be very helpful.
> What goes wrong when you try?
Aside from the use of a lot of Gnat only libraries (I can work around that), the attribute 'Address_Size doesn't seem to be supported by ObjectAda.  Also Long_Long_Integer seems to be another Gnat only implementation of Standard.

^ permalink raw reply	[flat|nested] 64+ messages in thread

* RE: DOM and SAX parsing in Ada
@ 2005-01-25  0:22 amado.alves
  0 siblings, 0 replies; 64+ messages in thread
From: amado.alves @ 2005-01-25  0:22 UTC (permalink / raw)
  To: Georg Bauhaus, comp.lang.ada

	>> ... http://softdevelcoop.org/software/xml_automaton ...
	
	> Let me be picky, it is a tokenizer of straightforward simplicity...

	Yes, strictly it's a tokenizer. I stand corrected. I called it parser because the damn thing is more than 50% of the XML parsers I write using it. Because to me a general purpose XML parser makes little sense. It just translates from one tree representation to another. And there is a zillion possible target representations. DOM, Yaml, many database languages, Booch containers, Ada 2005 containers, iterators, combinations thereof... I leave the choice to application time. And then what I need is a tokenizer. A straighforward, simple, effective, usable, robust, superfast one :-)




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2004-11-09  8:33     ` Martin Krischik
@ 2004-11-09 13:25       ` David Botton
  0 siblings, 0 replies; 64+ messages in thread
From: David Botton @ 2004-11-09 13:25 UTC (permalink / raw)


> 
> AdaCL.GCI is missting on "Ada Web and XML"

Not any more.

David Botton




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2004-11-09  0:56   ` David Botton
@ 2004-11-09  8:33     ` Martin Krischik
  2004-11-09 13:25       ` David Botton
  0 siblings, 1 reply; 64+ messages in thread
From: Martin Krischik @ 2004-11-09  8:33 UTC (permalink / raw)
  To: David Botton

<verï¿œffentlicht & per Mail versendet>

David Botton wrote:

> There are so many XML and Web related tools for Ada that I broke them
> now in to their own category, so please see
> http://www.adapower.com/reuse
> 
> 
> On 2004-11-08 19:24:41 -0500, David Botton <david@botton.com> said:
> 
>> There are 2 XML libs listed here and I will be adding another shortly:
>> 
>> See: http://www.adapower.com/index.php?Command=Class&ClassID=AdaLibs

AdaCL.GCI is missting on "Ada Web and XML" - As you know "AdaCL" is an
everything but the kitchen sink library. Still AdaCL.GCI should be
mentioned seperatly as it is the best CGI binding you can get and the only
one with support for file upload!

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com



^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2004-11-09  0:24 ` David Botton
@ 2004-11-09  0:56   ` David Botton
  2004-11-09  8:33     ` Martin Krischik
  0 siblings, 1 reply; 64+ messages in thread
From: David Botton @ 2004-11-09  0:56 UTC (permalink / raw)


There are so many XML and Web related tools for Ada that I broke them 
now in to their own category, so please see 
http://www.adapower.com/reuse


On 2004-11-08 19:24:41 -0500, David Botton <david@botton.com> said:

> There are 2 XML libs listed here and I will be adding another shortly:
> 
> See: http://www.adapower.com/index.php?Command=Class&ClassID=AdaLibs




^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: DOM and SAX parsing in Ada
  2004-11-08 23:24 DOM and SAX parsing in Ada Tim Roede
@ 2004-11-09  0:24 ` David Botton
  2004-11-09  0:56   ` David Botton
  2004-11-09  3:14 ` Steve
  1 sibling, 1 reply; 64+ messages in thread
From: David Botton @ 2004-11-09  0:24 UTC (permalink / raw)


There are 2 XML libs listed here and I will be adding another shortly:

See: http://www.adapower.com/index.php?Command=Class&ClassID=AdaLibs

See: The Ada Source Code treasury on http://www.adapower.com for an 
example of using the Ada/XML DOM (more examples to follow)

David Botton
http://www.adapower.com


On 2004-11-08 18:24:00 -0500, Tim Roede <timothy.j.roede@boeing.com> said:

> There is considerable interest in the group I am working with to provide
> XML parsing using both DOM and SAX parsing.  Does anyone have a name or
> a link to a suitable Ada library (similar to xerces)?
> 
> Please respond using email.
> 
> Thanks in advance
> 
> timothy.j.roede@boeing.com





^ permalink raw reply	[flat|nested] 64+ messages in thread

end of thread, other threads:[~2021-11-22 13:54 UTC | newest]

Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-08 23:24 DOM and SAX parsing in Ada Tim Roede
2004-11-09  0:24 ` David Botton
2004-11-09  0:56   ` David Botton
2004-11-09  8:33     ` Martin Krischik
2004-11-09 13:25       ` David Botton
2004-11-09  3:14 ` Steve
2005-01-20 12:16   ` okellogg
2005-01-21 18:09     ` Nick Roberts
2005-01-24 11:26       ` Alex R. Mosteo
2005-01-24 12:16         ` Marius Amado Alves
2005-01-24 20:17           ` Georg Bauhaus
2005-01-24 21:18             ` Pascal Obry
2005-01-24 19:02         ` Marc A. Criley
2005-01-25  9:50           ` Alex R. Mosteo
2005-01-25 15:29         ` Nick Roberts
2005-01-25 18:21           ` Marc A. Criley
2005-01-26  5:39             ` Nick Roberts
2005-01-26  7:37               ` Martin Krischik
2005-01-26 12:24               ` Jeff C
2005-01-26 16:16                 ` Nick Roberts
2005-01-26 16:46                   ` Georg Bauhaus
2005-01-27 19:45                     ` Nick Roberts
2005-01-26 22:14                   ` Brian May
2005-01-27  9:28                     ` Martin Krischik
2005-01-27 19:55                     ` Nick Roberts
2005-01-28 10:05                       ` Stephen Leake
2005-01-26 23:48                   ` Stephen Leake
2005-01-27 20:05                     ` Nick Roberts
2005-01-27 20:57                       ` Marc A. Criley
2005-01-27 22:11                         ` Nick Roberts
2005-01-27 22:24                           ` Pascal Obry
2005-01-28  0:29                             ` Nick Roberts
2005-01-28  7:22                               ` Pascal Obry
2005-01-28  2:56                           ` Steve
2005-01-28 13:32                             ` Georg Bauhaus
2005-01-28 15:25                             ` Nick Roberts
2005-01-28 10:23                           ` Stephen Leake
2005-01-29 11:58                             ` Simon Wright
2005-01-28 13:47                           ` Georg Bauhaus
2005-01-29 17:08                             ` Nick Roberts
2005-01-31 14:24                               ` Marc A. Criley
2005-01-28 13:54                           ` Georg Bauhaus
2005-01-29 11:54                           ` Simon Wright
2005-01-29 16:54                             ` Nick Roberts
2005-01-28 10:17                       ` Stephen Leake
2005-01-27  4:11                   ` Jeff C
2005-01-27 19:05                     ` Pascal Obry
2005-01-27 20:15                     ` Nick Roberts
2005-01-27 22:28                       ` Pascal Obry
2005-01-28  0:30                         ` Nick Roberts
2005-01-26 14:12               ` Marc A. Criley
2005-01-27  3:59                 ` Steve
2005-01-27  9:32                   ` Martin Krischik
2005-01-27 19:27                     ` Pascal Obry
2005-01-28  3:17                       ` Steve
2005-01-28  7:14                         ` Pascal Obry
2005-01-28 10:00                         ` Stephen Leake
2005-01-28  7:47                       ` Martin Krischik
2005-01-28  9:57                       ` Stephen Leake
2005-01-28 16:36                         ` Pascal Obry
2021-11-22 13:01   ` James Hitch
2021-11-22 13:31     ` Simon Wright
2021-11-22 13:54       ` James Hitch
2005-01-25  0:22 amado.alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox