XML generator

XML generator

[Wes Groleau]

Anyone know of an open source Ada tool to generate XML?

Not necessarily very sophisticated, but at least
a little more specific than Ada.Text_IO  :-)

I'm digging through a web search now, but
so far, either the "ADA" is not a language
or the tool only parses existing XML.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Ingo Marks]

Wes Groleau wrote:

> Anyone know of an open source Ada tool to generate XML?
> 
> Not necessarily very sophisticated, but at least
> a little more specific than Ada.Text_IO  :-)
> 
> I'm digging through a web search now, but
> so far, either the "ADA" is not a language
> or the tool only parses existing XML.

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

Regards

Re: XML generator

[Wes Groleau]

> > Anyone know of an open source Ada tool to generate XML?
> 
> http://libre.act-europe.fr/xmlada/

Thanks!  That was the first thing I saw,
but at first glance, it appeared to be
only a parser.  Now I see the part about
the DOM, which might help. I'm looking
at it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Wes Groleau]

> > > Anyone know of an open source Ada tool to generate XML?
> >
> > http://libre.act-europe.fr/xmlada/
> 
> Thanks!  That was the first thing I saw,
> but at first glance, it appeared to be
> only a parser.  Now I see the part about
> the DOM, which might help. I'm looking
> at it.

On second thought, it can be used to WRITE
XML only if I provide the callbacks--which
are the very parts I was trying to avoid writing.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Steve Doiel]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CE14210.AC3FC998@despammed.com...
>
> > > > Anyone know of an open source Ada tool to generate XML?
> > >
> > > http://libre.act-europe.fr/xmlada/
> >
> > Thanks!  That was the first thing I saw,
> > but at first glance, it appeared to be
> > only a parser.  Now I see the part about
> > the DOM, which might help. I'm looking
> > at it.
>
> On second thought, it can be used to WRITE
> XML only if I provide the callbacks--which
> are the very parts I was trying to avoid writing.

I belive this is only true if you're using SAX.  I think with DOM you can
create the structures in memory and then make a single call to write the
tree.

I have worked with XML/Ada a little on reading files (easy once you figure
it out) and have a couple of patches.  I think Emmanuel is very busy with
GPS right now so it may be a while before these show up in a new version.

SteveD

> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Wes Groleau]

> > On second thought, it can be used to WRITE
> > XML only if I provide the callbacks--which
> > are the very parts I was trying to avoid writing.
> 
> I belive this is only true if you're using SAX.  I think with DOM you can
> create the structures in memory and then make a single call to write the
> tree.

DOM is merely an allegedly language-independent
specification of features that must be available
in the internal representation.  Nothing about
writing out that I could see in the DOM spec.

And XML/Ada docs say that you'd have to write
callbacks to get anything out of a DOM tree.

What I am trying to do is avoid future bugs
in a tool that currently writes XML as little
independent pieces.  It has no concept of nesting
or of matching beginnings to ends, and so it's
very easy for a change to unintentionally make
the results invalid or malformed.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Pascal Obry]

Wes Groleau <wesgroleau@despammed.com> writes:

> And XML/Ada docs say that you'd have to write
> callbacks to get anything out of a DOM tree.

I'm not expert but this seems true for SAX. With the
DOM model in memory you have a set of methods to
walk on the tree and get various information for each 
node.

Pascal.

-- 

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

Re: XML generator

[Marin David Condic]

I've been tinkering with building a DOM in Ada & the last time I checked the
description of Level 1 for a document, there wasn't a "Write out this
document in XML text to a file or stream..." operation. Basically, you,
yourself, can walk the DOM tree & get back the data (often in its original
text form - although you may have to deal with normalization) and write your
own file that way. This may help prevent the errors Wes seemed to be
concerned about, but it may not eliminate them if your tree-walk isn't
correct.

The DOM spec was pretty lame with respect to how stuff gets into or out of
the DOM. IMHO, they *could* have specified some interfaces to parse XML
sources for input and reproduce valid XML as output. Of course, having it
specified (in a so-called "Language Neutral" way - "Language Neutral" as
long as your language is C++ or Java.) doesn't mean that all implementors
are going to give it to you or that its going to work correctly. It just
seems like they left some big, gaping holes in the spec.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:usn4ticmy.fsf@wanadoo.fr...
>
> I'm not expert but this seems true for SAX. With the
> DOM model in memory you have a set of methods to
> walk on the tree and get various information for each
> node.
>

Re: XML generator

[Wes Groleau]

> > And XML/Ada docs say that you'd have to write
> > callbacks to get anything out of a DOM tree.
> 
> I'm not expert but this seems true for SAX. With the
> DOM model in memory you have a set of methods to
> walk on the tree and get various information for each
> node.

Right.  But I need to write or find code that
goes the other way--instead of loading the XML
into a memory based DOM model, I need to write
the XML to a file.

To be more specific, I have to do:

--> ASIS --> info in memory --[a]--> XML file


but SAX and XML/Ada offer

XML file --> DOM model in memory --> user-written code

so I am looking for code that does transformation [a]
in a more logical way than what I already have.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[news.realtime.net]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CE2DF3C.682F07C4@despammed.com...
>
>
> To be more specific, I have to do:
>
> --> ASIS --> info in memory --[a]--> XML file
>
> so I am looking for code that does transformation [a]
> in a more logical way than what I already have.

We build code analysis and generation tools.  One tool
we are completing internally is a DTD "compiler".
     in: DTD,
     out:  native-target-language data structures/code for:
           a)  XML structures specified by DTD
           b) DTD-specific XML parser (fast!)
           c) DTD-specific XML generation.

The essential scheme defines one class per XML element
to hold the XML data.   Data access is direct,
rather than through a DOM interface.
Top level "parse XML for this specific DTD"
producing a tree of class instances",
and top-level "generate DTD-specific XML from this
tree of class instances" are generated.
We've done this for Java and COBOL.
We could easily do the same for Ada or Ada95.
Not open source, though.

This may be of considerable help, but it
seems to me that you wanted something
that guaranteed that you were producing
"correct" XML for a particular DTD.
(If you fill in the class tree properly,
you'll certainly get that).   But if your
concern is to verify that your application
always generates the correct XML (or
class structures), then what you appear
to want is an analyzer for your application,
that can find the series of XML-fragment
generation events and prove that all
sequences valid in your code will
compose those fragments correctly.
That's MUCH harder.   Our general tools
are designed to help with such tasks,
but that is probably pushing the envelope
of our ambitions.


Ira Baxter, PhD  CTO Semantic Designs
www.semdesigns.com   512-250-1018

Re: XML generator

[Marin David Condic]

O.K. but I'm not sure what you expect to find that will write out your XML
for you. The XML, presumably, is some reflection of the "info in memory"
part - which could be almost anything. I could imagine some version of:

--> ASIS --> DOM --> XML file

but the XML specification of the DOM didn't require some kind of output (or
input, for that matter. Big mistake IMHO) What you might build is:

--> ASIS --> DOM --> custom tree walk --> XML file

because that at least gives you a structure to work with. I just don't know
of any tools that do that for you already. (I've been tinkering with this a
bit, but don't have anything complete to offer. Maybe someone else did an
extension of the Ada XML stuff from: http://libre.act-europe.fr/xmlada/ but
it is unfortunately not part of the XML DOM specification.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CE2DF3C.682F07C4@despammed.com...
> Right.  But I need to write or find code that
> goes the other way--instead of loading the XML
> into a memory based DOM model, I need to write
> the XML to a file.
>
> To be more specific, I have to do:
>
> --> ASIS --> info in memory --[a]--> XML file
>
>
> but SAX and XML/Ada offer
>
> XML file --> DOM model in memory --> user-written code
>
> so I am looking for code that does transformation [a]
> in a more logical way than what I already have.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Aidan Skinner]

On Thu, 16 May 2002 10:30:26 -0400, Marin David Condic
<dont.bother.mcondic.auntie.spam@[> wrote in
<ac0fq4$isb$1@nh.pace.co.uk>:

>  --> ASIS --> DOM --> custom tree walk --> XML file

There could also be:

DTD --> perl script --> package spec/body

which derives from some nominal XML_Record type.

This could also be done with databases:

SQL --> perl script --> package spec/body

which derives from some nominal SQL_Record type.

Which could both dervie from some Storable_Record type which has
something like Read, Write, Get and Set procedures.

- Aidan
-- 
aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
finger for pgp key fingerprint |Unix Programmer/Admin actively seeking work
01AA 1594 2DB0 09E3 B850       |CV at http://www.velvet.net/~aidan/cv.txt
C2D0 9A2C 4CC9 3EC4 75E1       |Gis a job, go on, I can do that, go on, gis it.

Re: XML generator

[Marin David Condic]

I don't think that's where he was going. I think it was some version of
"I've got something parsed out using ASIS - now I want to take the
information I've derived and make it into an XML formatted text file..." It
was not necessarily a package spec/body and the problem may not be at all
amenable to DTD or databases. Do you know of some Ada code that will allow
you to create data in some form in memory and then say "Go put this out as
an XML file..."? It ought to be doable from a DOM implementation, but that
isn't one of the DOM requirements (maybe at level 3?) and I don't know of an
implementation *in Ada* that extends the DOM specification to provide that.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Aidan Skinner" <aidan@velvet.net> wrote in message
news:slrnae8mcs.tev.aidan@crushed.velvet.net...
> There could also be:
>
> DTD --> perl script --> package spec/body
>
> which derives from some nominal XML_Record type.
>
> This could also be done with databases:
>
> SQL --> perl script --> package spec/body
>
> which derives from some nominal SQL_Record type.
>
> Which could both dervie from some Storable_Record type which has
> something like Read, Write, Get and Set procedures.
>
> - Aidan
> --
> aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
> finger for pgp key fingerprint |Unix Programmer/Admin actively seeking
work
> 01AA 1594 2DB0 09E3 B850       |CV at http://www.velvet.net/~aidan/cv.txt
> C2D0 9A2C 4CC9 3EC4 75E1       |Gis a job, go on, I can do that, go on,
gis it.

Re: XML generator

[Aidan Skinner]

On Fri, 17 May 2002 09:40:26 -0400, Marin David Condic
<dont.bother.mcondic.auntie.spam@[> wrote in
<ac318a$9l6$1@nh.pace.co.uk>:

>  amenable to DTD or databases. Do you know of some Ada code that will allow

I'd be worried if you're writing XML for which a valid DTD cannot be
produced...

>  you to create data in some form in memory and then say "Go put this out as
>  an XML file..."? It ought to be doable from a DOM implementation, but that

Not automagically.

I have a generic package that I'm using which takes in a type, an
array of strings to represent the elements/propertys, and getproperty
and setproperty methods for that type which the set takes two strings
(the name of the property and the value to set it too) and the get
function takes one string (the name of the property) and returns a
string.

Read and Write functions are provided that utilise the passed in
methods, using the SAX parser in XML/Ada. It's not pretty, it's not
big and it's not clever, but it's easier than writing custom parsing
procedures every time. All the programmer has to do is the switch
statements in the methods to translate from strings to the appropriate
type and back again. Works nicely for the one-record-per-file
structure I tend to have.

- Aidan
-- 
aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
finger for pgp key fingerprint |Unix Programmer/Admin actively seeking work
01AA 1594 2DB0 09E3 B850       |CV at http://www.velvet.net/~aidan/cv.txt
C2D0 9A2C 4CC9 3EC4 75E1       |Gis a job, go on, I can do that, go on, gis it.

Re: XML generator

[Marin David Condic]

But that was the original problem. Scan through some data - output some
XML...(repeat) and somewhere along the line a program change might make
invalid XML. Besides, from what I know of DTD, I don't see how that helps a
program *produce* XML from whatever information it has in memory as its
running. It might help you *validate* it after you generated the XML, but
that's about it. Its also not some sort of general-purpose programming
language that could be used, say, to parse an arbitrary Ada program and
generage some sort of XML markup from it. Check out the original statement
of the problem & I'm sure you'll see that we've got a bit of a
communications gap going here...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Aidan Skinner" <aidan@velvet.net> wrote in message
news:slrnaebf9h.tev.aidan@crushed.velvet.net...
>
> I'd be worried if you're writing XML for which a valid DTD cannot be
> produced...
>

Re: XML generator

[Stephen Leake]

Aidan Skinner <aidan@velvet.net> writes:

> I have a generic package that I'm using which takes in a type, an
> array of strings to represent the elements/propertys, and
> getproperty and setproperty methods for that type which the set
> takes two strings (the name of the property and the value to set it
> too) and the get function takes one string (the name of the
> property) and returns a string.
> 
> Read and Write functions are provided that utilise the passed in
> methods, using the SAX parser in XML/Ada. It's not pretty, it's not
> big and it's not clever, but it's easier than writing custom parsing
> procedures every time. All the programmer has to do is the switch
> statements in the methods to translate from strings to the appropriate
> type and back again. Works nicely for the one-record-per-file
> structure I tend to have.

You could write an ASIS tool to write those switch statement procedures.

Although, if you go the ASIS route, it might make sense to write the
final package directly, rather than using a string-based generic.

-- 
-- Stephe

Re: XML generator

[Wes Groleau]

> I'd be worried if you're writing XML for which a valid DTD cannot be
> produced...

The original "requirements" were a set of sample
XML files without DTD refs.  I generated a DTD
by reverse engineering when I inherited the tool.
The tool currently has no XML knowledge at a low
level.  It writes out fragments that have to be
made valid XML by keeping the sequence of calls
correct.

So instead of something like

Element (Tag        => X,
         attributes => (...),
         content    => Element ( ...

which would presumably prevent syntax errors,
we have more like

Write ("<");
... conditionals
Write ("X");
... conditionals
Write ( ... attributes 
...etc.
...
...
Write (">"); -- Let's see, which tag ends here,
             -- and is it a start tag or an end tag?

I think this illustrates why I'm looking to find
or write something different.  :-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Marin David Condic]

Yeah. That could easily be subject to producing lots of hard to find errors.
What probably works better is doing something using the DOM to create the
tree. Some version of creating elements with tag names, adding attribute
nodes, adding child nodes of whatever content you need & when you're done,
spit it out to a file. That would be less error prone than trying to write
it out in bits & pieces.

The downside of the XMLAda implementation is that it isn't exactly "Object
Oriented" in its realization - discriminated records instead of tagged
records & inheritance. (Why? Given the DOM specification it would have
seemed more natural to do it all by some kind of inheritance from a base
node type...) That, and you'd have to basically do your own tree-walk to get
the output unless I missed seeing an "Output this document to a file or
stream" subprogram somewhere. But given the pre-packaged structure, at least
you can build up the XML a piece at a time & be reasonably sure you got it
right.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CE92E3E.907E487F@despammed.com...
>
> which would presumably prevent syntax errors,
> we have more like
>
> Write ("<");
> ... conditionals
> Write ("X");
> ... conditionals
> Write ( ... attributes
> ...etc.
> ...
> ...
> Write (">"); -- Let's see, which tag ends here,
>              -- and is it a start tag or an end tag?
>
> I think this illustrates why I'm looking to find
> or write something different.  :-)

Re: XML generator

[Pascal Obry]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> The downside of the XMLAda implementation is that it isn't exactly "Object
> Oriented" in its realization - discriminated records instead of tagged
> records & inheritance. (Why? Given the DOM specification it would have
> seemed more natural to do it all by some kind of inheritance from a base
> node type...) 

Not a problem, just propose a patch to have XMLAda more OO... No kidding,
XMLAda is ours, it is up to us to make it better...

Pascal.

-- 

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

Re: XML generator

[Marin David Condic]

A "patch" in this case would pretty much amount to a rewrite. Its based on a
discriminated record. How could you realize an OO implementation based on a
"Node" class with descendents for all the different XML elements without
pretty much annihilating everything that is already there? Check out the
description of DOM level 1 here:
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html#ID-BB
ACDC08 and you'll notice that the XMLAda implementation - while it may
satisfy the requirements - doesn't exactly follow in the spirit of
everything inheriting from a Node class. I'm not criticizing - just
observing that a more OO design could have been done that would line up
better with the spec. Changing something this fundamental would likely
butcher it.

Even if you could somehow re-map the whole thing into tagged records with
inherited operations, you'd be dramatically changing the interface which
would kill anything currently using it. You could certainly salvage large
chunks of code but I'd think it would be better to develop one from bottom
dead center than to try to hammer XMLAda into a whole different mold.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:usn4l4kdm.fsf@wanadoo.fr...
>
> Not a problem, just propose a patch to have XMLAda more OO... No kidding,
> XMLAda is ours, it is up to us to make it better...
>

Re: XML generator

[Wes Groleau]

> O.K. but I'm not sure what you expect to find that will write out your XML

I didn't really "expect" to find it, but I thought there was a good
chance
something similar enough existed to make it more cost-effective to
modify
instead of starting over.

> --> ASIS --> DOM --> XML file
>
< [ or ]
> 
> --> ASIS --> DOM --> custom tree walk --> XML file

What we have now is 

ASIS --> little pieces of XML files.

Because the little pieces are concatenated in a "flat"
sequence, i.e., by sequential code that has not concept
of nesting, and because there is no coupling among the
routines that generate the little pieces, it is very easy
for maintenance to introduce bugs that result in
bogus stuff like

  <tag1 name="value"
     <tag2
        <tag3
     />
  </tag1>

So, it looks like I'm going to have to write it myself.
Won't be that hard, but I was just trying for the
Ben Franklin approach.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Georg Bauhaus]

Wes Groleau <wesgroleau@despammed.com> wrote:
: 
:  <tag1 name="value"
:     <tag2
:        <tag3
:     />
:  </tag1>

one ad hoc workaround is using the template machine built into
Ada Web Server, like in Jon Bentley's letter forms.
perhaps together with a 'write attribute for you info pieces?

-- Georg

Re: XML generator

[Wes Groleau]

> one ad hoc workaround is using the template machine built into
> Ada Web Server, like in Jon Bentley's letter forms.
> perhaps together with a 'write attribute for you info pieces?

Hmm - I'll look into that.  Thanks.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Steve Doiel]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3CE2875B.F2A54C0D@despammed.com...
[snip]
> DOM is merely an allegedly language-independent
> specification of features that must be available
> in the internal representation.  Nothing about
> writing out that I could see in the DOM spec.
>
Agreed.

> And XML/Ada docs say that you'd have to write
> callbacks to get anything out of a DOM tree.
>

Right.  I just reviewed XML/Ada.  While there are facilities to read a text
file containing XML into a DOM tree (input_sources.file) there are currently
no sources to write the DOM tree as a text file.

If you contact ACT for support I'm sure they would be more than happy to put
something together.

> What I am trying to do is avoid future bugs
> in a tool that currently writes XML as little
> independent pieces.  It has no concept of nesting
> or of matching beginnings to ends, and so it's
> very easy for a change to unintentionally make
> the results invalid or malformed.
>

I don't know whether it would be an improvement over what you have, but
writing recursive routine to dump the content of a DOM tree producing a
valid XML file would (I think) be trivial.

SteveD

> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[Emmanuel Briot]

> > And XML/Ada docs say that you'd have to write
> > callbacks to get anything out of a DOM tree.
> >
> 
> Right.  I just reviewed XML/Ada.  While there are facilities to read a text
> file containing XML into a DOM tree (input_sources.file) there are currently
> no sources to write the DOM tree as a text file.


There wasn't anything in DOM 2.0, and that is what XML/Ada implements. I think
provision for writting out the tree has been added to DOM 3.0, but I haven't
had time to look into that, and ACT hasn't had any request for this extended
operations so far. So this is quite low on my priority list.

Of course, I would be happy to look at patches or suggestions (thanks Steve for
all you already sent, even if it hasn't been integrated yet... GPS is currently
higher on the list)


There is a small debug function in XML/Ada (something like Print, I think),
that is used for the internal testsuite. You might want to take a look at that
as a starting point.

Emmanuel

Re: XML generator

[Wes Groleau]

> I don't know whether it would be an improvement over what you have, but
> writing recursive routine to dump the content of a DOM tree producing a
> valid XML file would (I think) be trivial.

I don't think it would be "trivial"
but it should not be too difficult.

I just figured (apparently incorrectly)
that somebody may have already done it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: XML generator

[David Botton]

If you are on Win32, try GNATCOM and the MS XML control. I've used it for
some time now with great success.

David Botton

> On second thought, it can be used to WRITE
> XML only if I provide the callbacks--which
> are the very parts I was trying to avoid writing.

Re: XML generator

[achrist]

David Botton wrote:
> 
> If you are on Win32, try GNATCOM and the MS XML control. I've used it for
> some time now with great success.
> 

I've used it some a few months ago, but I didn't think that I had 
great success. My application was an editor and viewer for some 
particular XML data -- involved reading a large (maybe 1MB, 1000 
items in a tree) file of XML, providing interactive access and update 
for the XML contents, and than writing it back out.  I succeeded in 
doing that, but the MSXML  API was not very good in providing update 
functions, from what I found. The updating was done by providing the 
new XML data flattened into a string representation, regardless of 
how many levels of structure or how many attributes it contained.  
This is a little much of brute force and ignorance to look like a 
good idea in Ada.  Maybe I missed something.  I would like to see 
some good examples of XML creation and manipulation in Ada.  

Maybe I missed something or didn't understand how it was supposed to 
work.  My recollection is that examples in some other languages, eg VB, 
were able to have the program structure match the XML data structure
a little better, but they did that by being less type-safe than the Ada
interface to MSXML.  Maybe I missed something.  I would like to 
see some good examples of XML creation and manipulation in Ada.  

My impression was that MSXML was designed to provide access to XML 
data, but that it was very weak for updating of XML data. 


Al