Experiences of XML parser generators for Ada?

Experiences of XML parser generators for Ada?

[Daniel W]

Greetings, I am currently looking for a way to automatically create an Ada 
parser/generator for an XML schema. Does anyone have any first hand 
experience with such tasks? Any information on methods and tools would be 
appreciated!

Thanks, Daniel

Re: Experiences of XML parser generators for Ada?

[Georg Bauhaus]

Daniel W <dawe@syntell.se> wrote:
: 
: 
: Greetings, I am currently looking for a way to automatically create an Ada 
: parser/generator for an XML schema. Does anyone have any first hand 
: experience with such tasks? Any information on methods and tools would be 
: appreciated!

Try http://www.xmlbooster.com/ada.html

Another option is to write an XSL transformation that turns XML
document instances into declarations.


-- Georg

Re: Experiences of XML parser generators for Ada?

[Martin Krischik]

Daniel W wrote:

> 
> 
> Greetings, I am currently looking for a way to automatically create an Ada
> parser/generator for an XML schema. Does anyone have any first hand
> experience with such tasks? Any information on methods and tools would be
> appreciated!
> 
> Thanks, Daniel

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

You would have found that yourself if you had googled a bit ;-) .

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

Re: Experiences of XML parser generators for Ada?

[Adrien Plisson]

Daniel W wrote:
> Greetings, I am currently looking for a way to automatically create an Ada
> parser/generator for an XML schema. 

he asks for a parser generator: it is a piece of software that reads a shema 
and generate a parser specifically tailored to parse XML fragments that 
complies to this shema, and nothing else...

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

you answer (not very friendly) with a generic XML parser...

-- 
rien

Re: Experiences of XML parser generators for Ada?

[Daniel W]

Thank you for your succinct clarification. More specifically I'm asking for 
persons with experience of the parser generator. I actually have XMLBooster 
downloaded, but as I said, I'm sort of short on experience.... :-)

Have a very pleasant weekend, y'all

"Adrien Plisson" <aplisson-news@stochastique.net> wrote in message 
news:41b02dfe$0$25046$ba620e4c@news.skynet.be...
> Daniel W wrote:
>> Greetings, I am currently looking for a way to automatically create an 
>> Ada
>> parser/generator for an XML schema.
>
> he asks for a parser generator: it is a piece of software that reads a 
> shema and generate a parser specifically tailored to parse XML fragments 
> that complies to this shema, and nothing else...
>
> Martin Krischik wrote:
>> XML/Ada: http://libre.act-europe.fr/xmlada
>
> you answer (not very friendly) with a generic XML parser...
>
> -- 
> rien 

Re: Experiences of XML parser generators for Ada?

[Adrien Plisson]

Daniel W wrote:
> Thank you for your succinct clarification. More specifically I'm asking for 
> persons with experience of the parser generator. I actually have XMLBooster 
> downloaded, but as I said, I'm sort of short on experience.... :-)

well, i don't have any experience with parser generator (excepted with 
lex), but i would like to share my experience:

i designed a software composed of 2 parts. all parts were written in a 
different language, and each part was executing in its own context 
(think of 2 different computers). i choosed XML as the format for 
marshaled data accross the communication medium.

i first downloaded a standard XML parser (Xerces) and tried it. it was 
so slow that i could not continue with it. since i was only using a 
subset a XML (no dtd, no validation, no entity reference, only one 
encoding), i decided to write my own XML parser and XML generator. i got 
  70x performance boost.

now if i look back, i think it would have been better if i had defined 
my own protocol and not used XML:
- the xml fragment were all generated then parsed by software under my 
control, no user intervention. so there was no need for something human 
readable.
- i was mostly transmitting numeric values. since xml is a text format, 
performances were teared down by all the conversions from binary to 
string and back to binary.
- since i was mostly transmitting numeric values, all my text nodes were 
  shorter than the xml element type enclosing those values. this leads 
to HUGE overhead. e.g.: <detectionTreshold>84</detectionTreshold> 
encoded in Unicode is 84 bytes long, but the value expressed here is 
only 1 byte long.
- the only thing xml allowed me was extensibility at no cost, in a case 
were i was not really needing it.

so here comes my advice: think twice before using xml.
xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
TEXT. for everything else, a basic binary protocol with some well 
defined rules to follow (endianness, size of data) will really be more 
efficient. plus, a basic binary protocol do not need complicated parsers...

here was my experience, i hope you find it useful.

-- 
rien

Re: Experiences of XML parser generators for Ada?

[Dmitry A. Kazakov]

On Sat, 04 Dec 2004 00:33:22 +0100, Adrien Plisson wrote:

> so here comes my advice: think twice before using xml.
> xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
> TEXT.

Human readable? I have an impression that punched cards were more readable!
XML reminds me one implementation of Algol 60, in which all keyword were
upper case put in quotes, e.g. 'BEGIN'. Though, even that was more readable
than XML.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Experiences of XML parser generators for Ada?

[Marius Amado Alves]

>>so here comes my advice: think twice before using xml.
>>xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
>>TEXT.
> 
> Human readable? I have an impression that punched cards were more readable!
> XML reminds me one implementation of Algol 60, in which all keyword were
> upper case put in quotes, e.g. 'BEGIN'. Though, even that was more readable
> than XML.

Indeed XML has failed its two main purposes, which were to be readable 
by humans and efficiently processable by machines. Maybe there is a 
third, unwritten, more important need that XML has met, given its 
apparent widespread adoption. Otherwise XML must be the greatest IT hoax 
spanning two millenia.

Re: Experiences of XML parser generators for Ada?

[Martin Krischik]

Marius Amado Alves wrote:

>>>so here comes my advice: think twice eyeing using xml.
>>>xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE
>>>TEXT.
>> 
>> Human readable? I have an impression that punched cards were more
>> readable! XML reminds me one implementation of Algol 60, in which all
>> keyword were upper case put in quotes, e.g. 'BEGIN'. Though, even that
>> was more readable than XML.
> 
> Indeed XML has failed its two main purposes, which were to be readable
> by humans and efficiently processable by machines. Maybe there is a
> third, unwritten, more important need that XML has met, given its
> apparent widespread adoption.

Can be rendered by a browser for easier reading. But it failed on that one
too - see below.

> Otherwise XML must be the greatest IT hoax 
> spanning two millenia.

I think the failure on "readable by humans" is partly based on using the
wrong format.

i.E: using:

<name value="Martin" />

instead of:

<name>Martin</name>

If I look at an XMI document there is in fact no text which could to be
rendered by browser:

http://cvs.sourceforge.net/viewcvs.py/adacl/adacl/Model/AdaCL.xmi?view=markup

See, no text - just tags with parameters.

With Regards

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

Re: Experiences of XML parser generators for Ada?

[Jeffrey Carter]

Martin Krischik wrote:
> 
> I think the failure on "readable by humans" is partly based on using the
> wrong format.
> 
> i.E: using:
> 
> <name value="Martin" />
> 
> instead of:
> 
> <name>Martin</name>

Shouldn't we prefer

Name : begin
    "Martin";
end Name;

?:)

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Experiences of XML parser generators for Ada?

[Dmitry A. Kazakov]

On Sun, 05 Dec 2004 16:27:58 GMT, Jeffrey Carter wrote:

> Martin Krischik wrote:
>> 
>> I think the failure on "readable by humans" is partly based on using the
>> wrong format.
>> 
>> i.E: using:
>> 
>> <name value="Martin" />
>> 
>> instead of:
>> 
>> <name>Martin</name>
> 
> Shouldn't we prefer
> 
> Name : begin
>     "Martin";
> end Name;
> 
> ?:)

Nope, it should be:

Martin : begin -- (:-))
    name
end Martin;

Though that depends:

- declaration: Martin : Name
- association: Name => "Martin"
- label: <<Martin>> Name
- initialization: Name := "Martin" or Martin := Name
- definition: Martin is [new] name
- renaming: Martin renames Name
- extension: Name with "Martin"
- implementation: for Name use "Martin"

Have I missed something? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Experiences of XML parser generators for Ada?

[Georg Bauhaus]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
:>>so here comes my advice: think twice before using xml.
:>>xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
:>>TEXT.
:> 
:> Human readable? I have an impression that punched cards were more readable!
:> XML reminds me one implementation of Algol 60, in which all keyword were
:> upper case put in quotes, e.g. 'BEGIN'. Though, even that was more readable
:> than XML.
: 
: Indeed XML has failed its two main purposes, which were to be readable 
: by humans and efficiently processable by machines.

Complete nonsense.

First, as has been demonstrably envisioned by the creators of
SGML, the XML subset is NOT designed to be readable-in-the-sense-of
"as easy to read as your well typeset sunday newspaper."

What is meant by "human readable text" is that structured values
can be represented as text, explicitly naming the parts and relations.
If a human looks at three bit patterns, he/she will have to
know context and a bit of luck in order to be able to interpret
the bit patterns like a computer does.
If a human looks at

  <issue-date   year="2003"  month="4" day="31" />

the three bitpatterns have been made structured human readable text,
and it is a lot more clear what is meant when compared to three
bit patterns.
Imagine you are hunting bugs, e.g. Year 2000 bugs in a four-company
distributed program, and all you get as diagnostic aid is decimal
representations of bare, unnamed numbers buried in a server program's
trace output, 
Then you cannot tell the month value and the day value apart,
same size, ranges overlap.
There might be ambiguities if there is no minimum markup, like a
comma separating values.
You can't tell without further research or luck whether these value
represent an issue date or a birth date.

If you want less intrusive markup, for example because you are an author,
you want to type the markup yourself, but you still want your document
instances almost as readable as plain text, say so. Write "SHORTAG YES"
for example, into your SGML declaration. Use more than the XML subset
then.

Second, XML parsing can be a lot more efficient than SGML parsing with
SHORTREF YES, SHORTTAG YES, CONCUR etc.
XML validation, if needed, has to be compared to the checking that
your program does when it doesn't use XML for middleware data
communication.
Of course, as has been said in this thread, if you transform
values from their machine representation into text, and back, this
will take time.  But this time is not necessarily lost. What you
get is a program-independent represenation of data.

If you don't need all this, then I guess you can brew your own data
representation, and let all your programs communicate with themselves.


-- Georg

Re: Experiences of XML parser generators for Ada?

[Martin Krischik]

Georg Bauhaus wrote:

> Marius Amado Alves <amado.alves@netcabo.pt> wrote:

> What is meant by "human readable text" is that structured values
> can be represented as text, explicitly naming the parts and relations.
> If a human looks at three bit patterns, he/she will have to
> know context and a bit of luck in order to be able to interpret
> the bit patterns like a computer does.
> If a human looks at
>
>   <issue-date   year="2003"  month="4" day="31" />

But was not the idea of XML that - by using an appropriate CSS - the data
can be rendered by a browser for easy reading? And don't you need to
seperate data from markup to archive that:

<issue-date><year>2003</year><month>4</month><day>31</day></issue-date>

Martin

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

Re: Experiences of XML parser generators for Ada?

[Georg Bauhaus]

Martin Krischik <martin@krischik.com> wrote:
: Georg Bauhaus wrote:
: 
:>
:>   <issue-date   year="2003"  month="4" day="31" />
: 
: But was not the idea of XML that - by using an appropriate CSS - the data
: can be rendered by a browser for easy reading? And don't you need to
: seperate data from markup to archive that:

The idea of XML, and of *separating* markup from format, predates
both HTML and CSS. (And note how the required "alt" attribute of the
HTML "img" tag is rendered by many browsers...)

Usually, a style sheet and an XML document instance _are_ separate,
they can be combined freely using one processing instruction.

: <issue-date><year>2003</year><month>4</month><day>31</day></issue-date>

If, for some reason (other than related to rendering), you need to
transform your data into the line above (and not into HTML for rendering),

  <xsl:template match='issue-date'>
    <issue-date>
      <year><xsl:value-of select='@year'/></year>
      <month><xsl:value-of select='@month'/></month>
      <day><xsl:value-of select='@date'/></day>
    </issue-date>
  </xsl:template>

(If the source and destination names "year", "month", "day", are known
to stay, you could even reuse the attribute names for element names.)

-- Georg

Re: Experiences of XML parser generators for Ada?

[Pascal Obry]

Martin Krischik <martin@krischik.com> writes:

> But was not the idea of XML that - by using an appropriate CSS - the data
> can be rendered by a browser for easy reading? And don't you need to
> seperate data from markup to archive that:

Certainly not! XML is a way to structure information (document, data, ...) it
is a simple SGML (SGML has been around since a long time). The problem with
SGML was that it was too complex to be widespead... and tools were very
expensive. In this sense XML is very successful!

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

Re: Experiences of XML parser generators for Ada?

[Florian Weimer]

* Pascal Obry:

> Certainly not! XML is a way to structure information (document, data, ...) it
> is a simple SGML (SGML has been around since a long time). The problem with
> SGML was that it was too complex to be widespead... and tools were very
> expensive. In this sense XML is very successful!

And its limitations begin to show, so more complexity is added, until
the XML toolchest is much more complex than the SGML one ever was.

The same thing has happened to DAP and LDAP.

Re: Experiences of XML parser generators for Ada?

[David Botton]

Rule #3 It's called marketing appeal. Certainly though it does have a 
place for things like configuration files and non-real time data 
interchange between diverse applications.

On 2004-12-04 06:40:25 -0500, Marius Amado Alves <amado.alves@netcabo.pt> said:
>  Maybe there is a third, unwritten, more important need that XML has met

Re: Experiences of XML parser generators for Ada?

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Sat, 04 Dec 2004 00:33:22 +0100, Adrien Plisson wrote:
: 
:> so here comes my advice: think twice before using xml.
:> xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
:> TEXT.
: 
: Human readable? I have an impression that punched cards were more readable!

Punch cards hardly tell you what the holes mean?


: XML reminds me one implementation of Algol 60, in which all keyword were
: upper case put in quotes, e.g. 'BEGIN'. Though, even that was more readable
: than XML.

This is a misunderstanding of what readibility means here.
Please see my other reply in this thread.

-- Georg

Re: Experiences of XML parser generators for Ada?

[Dmitry A. Kazakov]

On Sat, 4 Dec 2004 14:01:47 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Sat, 04 Dec 2004 00:33:22 +0100, Adrien Plisson wrote:
>: 
>:> so here comes my advice: think twice before using xml.
>:> xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
>:> TEXT.
>: 
>: Human readable? I have an impression that punched cards were more readable!
> 
> Punch cards hardly tell you what the holes mean?

Sure, each hole had a tag printed on the card! See:

http://www.fourmilab.ch/documents/univac/cards.html

Deluxe punchers even printed the punched text on the card, redundant but
beloved by suckers! The positions 73..80 were usually reserved for
numbering, very handy if your hands are trembling! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Experiences of XML parser generators for Ada?

[Daniel W]

OK, let me just clarify what the application I'm looking at is all about.

I am involved in an effort where a government agency has to define a 
protocol (syntax and semantics) with which subsystems developed by several 
different industries shall communicate. TCP/IP is applicable as transmission 
level protocols, but on top of that the messages to be passed between 
subsystems need to be specified specifically for this purpose. The 
transmission between subsystems is within a safety critical system.

We choose to model the syntax of the messages in XML schema, basically on 
the (delivered) assumption that it provides good modelling tools that let 
the domain experts see through to the domain stuff, and on the (yet to be 
proven) assumption that the schema could be used to automatically generate 
the parser (for the receiving end) and the generator (for the sending end) 
in a fairly arbitrary programming language with reasonable preformance, 
without to much requirements for run-time environments ((e.g. minimal 
limitations on hw/RTOS).

We are now basically through the domain stuff and would want to see our 
assumptions confirmed.

/Daniel

"Adrien Plisson" <aplisson-news@stochastique.net> wrote in message 
news:41b0f749$0$25068$ba620e4c@news.skynet.be...
> Daniel W wrote:
>> Thank you for your succinct clarification. More specifically I'm asking 
>> for persons with experience of the parser generator. I actually have 
>> XMLBooster downloaded, but as I said, I'm sort of short on experience.... 
>> :-)
>
> well, i don't have any experience with parser generator (excepted with 
> lex), but i would like to share my experience:
>
> i designed a software composed of 2 parts. all parts were written in a 
> different language, and each part was executing in its own context (think 
> of 2 different computers). i choosed XML as the format for marshaled data 
> accross the communication medium.
>
> i first downloaded a standard XML parser (Xerces) and tried it. it was so 
> slow that i could not continue with it. since i was only using a subset a 
> XML (no dtd, no validation, no entity reference, only one encoding), i 
> decided to write my own XML parser and XML generator. i got 70x 
> performance boost.
>
> now if i look back, i think it would have been better if i had defined my 
> own protocol and not used XML:
> - the xml fragment were all generated then parsed by software under my 
> control, no user intervention. so there was no need for something human 
> readable.
> - i was mostly transmitting numeric values. since xml is a text format, 
> performances were teared down by all the conversions from binary to string 
> and back to binary.
> - since i was mostly transmitting numeric values, all my text nodes were 
> shorter than the xml element type enclosing those values. this leads to 
> HUGE overhead. e.g.: <detectionTreshold>84</detectionTreshold> encoded in 
> Unicode is 84 bytes long, but the value expressed here is only 1 byte 
> long.
> - the only thing xml allowed me was extensibility at no cost, in a case 
> were i was not really needing it.
>
> so here comes my advice: think twice before using xml.
> xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
> TEXT. for everything else, a basic binary protocol with some well defined 
> rules to follow (endianness, size of data) will really be more efficient. 
> plus, a basic binary protocol do not need complicated parsers...
>
> here was my experience, i hope you find it useful.
>
> -- 
> rien
> 

Re: Experiences of XML parser generators for Ada?

[Marc A. Criley]

"Adrien Plisson" <aplisson-news@stochastique.net> wrote :
> so here comes my advice: think twice before using xml.
> xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE
> TEXT.

Like any other technology, XML is well-suited to a certain class of problem
domains and not so well suited to others.  I agree that XML was an
inappropriate choice for the purpose to which you were applying it--internal
data transfer between two tightly coupled subsytems.

The reason for XML's existence is quite public:  data interoperability
between loosely coupled systems.  The human readability of XML is handy, but
basically irrelevant to its intended purpose.

As a real-world example, one of the tools we've developed at my day job
generates a report of events extracted from log files and correlated with
the expected sequence of events.  I directed that the report be generated
using XML, which made it easier to convert to HTML for viewing in a browser,
and to ease the creation of possible follow-on tools that might find the
information in that report to be useful as input.

Guess what?  This has just happened.  A new tool is now being created will
use the generated report as input, since the correlated, logged events can
serve as triggers as to when to perform additional post-processing of the
data logged by the system.  Because the report is represented in XML, no
parser needed to be written and no interpretation of the contents needed to
be implemented, it was all there in the XML schema and files.  Other than us
developers, no one will ever need to look at the raw XML form of the report,
but because of the interoperability infrastructure we have with XML, writing
and parsing data files comprises only a very small part of the overall
development effort.

> for everything else, a basic binary protocol with some well
> defined rules to follow (endianness, size of data) will really be more
> efficient. plus, a basic binary protocol do not need complicated
parsers...

Assuming of course that over time the documentation of the binary format
remains up-to-date and locatable!  At least with a halfway-reasonable XML
definition you can infer something about the content's layout and structure
just by looking at the file.  (And XML parsers are readily available, so
their complexity is of little concern to me.)

On-topic Ada reference :-) --  XIA (XPath In Ada) is coming along nicely.
The next version, 0.30, which includes a partial implementation of predicate
filtering, will be made available in the very near future.
(www.mckae.com/xia.html)

Marc A. Criley
McKae Technologies
www.mckae.com

Re: Experiences of XML parser generators for Ada?

[Robert C. Leif]

   
   I have had the experience of manually creating a dual system of XML
schema and Ada for Cytometry, CytometryML.  This is described, at length in
the CytometryML page of my web site, WWW.NewportInstruments.com. I also gave
a Birds of a Feather Presentation in absentia at SIGAda 2004, which is also
available on the Ada_Med page and includes audio. 
   Translation of most of Ada into XML and XML schemas is straightforward
and probably can be facilitated by constructing tools based on ASIS.
However, when the XML including schemas is defined as elements with a hidden
type, there could be a problem.  One simple solution is to declare a type
with a name which is a concatenation of the XML element's name and the
suffix type.  In many case, it would be appropriate to make the Ada type
private.
I have created numeric data-types in Ada and XML schema with the same names.
As luck would have it, these ECMA based names are also used for MathCad. I
have also created Ada bounded strings that include character sets.  These
provide a close approximation of XML strings.  XML strings can also include
a constraint based on a minimum number of characters.
I still strongly believe a description of Ada in the form of XML schema
should be created.  The goal is to construct eventually a programming
environment including an editor based on XML. 
Bob Leif

Re: Experiences of XML parser generators for Ada?

[Björn Persson]

Robert C. Leif wrote:

> I have also created Ada bounded strings that include character sets.

What do you mean with "strings that include character sets"? Do the 
strings carry information about which character encoding they're encoded 
in? In that case I'd be interested in looking at your implementation.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Experiences of XML parser generators for Ada?

[Robert C. Leif]

   The "HUGE overhead.  e.g.: <detectionTreshold>84</detectionTreshold>" is
being solved by the creation of "XML Binary Characterization Properties"
http://www.w3.org/TR/xbc-properties/. 
>From Section 4.3.2 Description
" Furthermore, a schema-based encoding of an XML document can achieve a
degree of compactness by using prior knowledge about the structure and
content of a document.  A serialization is schema-based if it uses
information from the document's schema to achieve a better degree of
compactness. This information could be used later as the document is
processed or reconstituted. It is worth pointing out that although not self
contained, a schema-based encoding is not inherently lossy given that, in
principle, a decoder can reproduce the data model using both the encoding
and the schema. Thus, as with other techniques, a schema-based encoding can
be lossy or loss-less."
   If the schema data-types are the same as the Ada data-types, the space
required should be approximately the same.  The real problem is that the Ada
community has not been involved with setting W3C standards.  Ada needs a
complete set of XML_IO packages including being able to create XHTML Strict.
   Bob Leif
   -------
   Adrien Plisson wrote:
   Message: 2
   Date: Sat, 04 Dec 2004 00:33:22 +0100
   From: Adrien Plisson <aplisson-news@stochastique.net>
   Subject: Re: Experiences of XML parser generators for Ada?
   To: comp.lang.ada@ada-france.org
   Message-ID: <41b0f749$0$25068$ba620e4c@news.skynet.be>
   Content-Type: text/plain; charset=us-ascii; format=flowed
   
   Daniel W wrote:
   > Thank you for your succinct clarification. More specifically I'm asking
for 
   > persons with experience of the parser generator. I actually have
XMLBooster 
   > downloaded, but as I said, I'm sort of short on experience.... :-)
   
   well, i don't have any experience with parser generator (excepted with 
   lex), but i would like to share my experience:
   
   i designed a software composed of 2 parts. all parts were written in a 
   different language, and each part was executing in its own context 
   (think of 2 different computers). i choosed XML as the format for 
   marshaled data accross the communication medium.
   
   i first downloaded a standard XML parser (Xerces) and tried it. it was 
   so slow that i could not continue with it. since i was only using a 
   subset a XML (no dtd, no validation, no entity reference, only one 
   encoding), i decided to write my own XML parser and XML generator. i got 
     70x performance boost.
   
   now if i look back, i think it would have been better if i had defined 
   my own protocol and not used XML:
   - the xml fragment were all generated then parsed by software under my 
   control, no user intervention. so there was no need for something human 
   readable.
   - i was mostly transmitting numeric values. since xml is a text format, 
   performances were teared down by all the conversions from binary to 
   string and back to binary.
   - since i was mostly transmitting numeric values, all my text nodes were 
     shorter than the xml element type enclosing those values. this leads 
   to HUGE overhead. e.g.: <detectionTreshold>84</detectionTreshold> 
   encoded in Unicode is 84 bytes long, but the value expressed here is 
   only 1 byte long.
   - the only thing xml allowed me was extensibility at no cost, in a case 
   were i was not really needing it.
   
   so here comes my advice: think twice before using xml.
   xml is a very powerful tool for DYNAMICALLY STRUCTURED HUMAN READABLE 
   TEXT. for everything else, a basic binary protocol with some well 
   defined rules to follow (endianness, size of data) will really be more 
   efficient. plus, a basic binary protocol do not need complicated
parsers...
   
   here was my experience, i hope you find it useful.
   
   -- 
   rien

Re: Experiences of XML parser generators for Ada?

[Adrien Plisson]

Robert C. Leif wrote:
>    The "HUGE overhead.  e.g.: <detectionTreshold>84</detectionTreshold>" is
> being solved by the creation of "XML Binary Characterization Properties"
> http://www.w3.org/TR/xbc-properties/. 

this is a very interresting paper. thanks for the pointer. although it 
does not solve the problem, it just clarifies and categorizes it.

>    If the schema data-types are the same as the Ada data-types, the space
> required should be approximately the same. 

i don't agree with this: if the space is the same, it means you would 
not have any markup, just data, so there would be no need for xml.

> The real problem is that the Ada
> community has not been involved with setting W3C standards.  Ada needs a
> complete set of XML_IO packages including being able to create XHTML Strict.

well, Ada has nothing to do with w3c. it is the our job, as Ada 
programmers to design and implement a library providing those features 
(as Xml/Ada does). it shall never be part of the standard.

-- 
rien

Re: Experiences of XML parser generators for Ada?

[Lionel Draghi]

Adrien Plisson a ï¿œcrit :
...
> well, Ada has nothing to do with w3c. it is the our job, as Ada 
> programmers to design and implement a library providing those features 
> (as Xml/Ada does). it shall never be part of the standard.

Yes, but

    type Money is range 1 .. 10;

becomes

    name="TN" type="xsd:int"

in WSDL. The range is lost.

Maybe some more Ada awareness at w3c could have cause this semantics to 
be included. (If it is, please let me know)
I think ranges are important when describing an interface, especially 
for web services.
I don't want client to continuously cause exceptions in my server, just 
because there is no way to let them know about the limits.

Once more back to strong typing benefits discussion :-)

-- 
Lionel Draghi

Re: Experiences of XML parser generators for Ada?

[Georg Bauhaus]

Lionel Draghi <Lionel.nospam.Draghi@ada-france.org> wrote:
: Adrien Plisson a ?crit :
: ...
:> well, Ada has nothing to do with w3c. it is the our job, as Ada 
:> programmers to design and implement a library providing those features 
:> (as Xml/Ada does). it shall never be part of the standard.
: 
: Yes, but
: 
:    type Money is range 1 .. 10;
: 
: becomes
: 
:    name="TN" type="xsd:int"
: 
: in WSDL. The range is lost.
: 
: Maybe some more Ada awareness at w3c could have cause this semantics to 
: be included. (If it is, please let me know)

This problem has been discussed during XML Schema design.
In XML Schema you have some form of ranges in the type libraries.

pro: You don't need to bother to make a good external format,
     just lazily copy your data definitions to an XML stream

medium: If you need to carry type information you can make this
     explicit in a type="..." attribute. (This is then not standards
     based, but it gives more flexibility than a parser that says:
     range error at l.1234, and the just stops.)

con: Freezing the range might not meet any expectation but your
     program's

: I don't want client to continuously cause exceptions in my server, just 
: because there is no way to let them know about the limits.

Use 'Valid and so on. Web services or not, I/O is always a possible
source of surprises. :-)  A secure server cannot rely on external input
anyway, I'd guess.

 
: Once more back to strong typing benefits discussion :-)

The flexible solution is Relax NG.

Re: Experiences of XML parser generators for Ada?

[Lionel Draghi]

Georg Bauhaus a ï¿œcrit :
...
> This problem has been discussed during XML Schema design.
> In XML Schema you have some form of ranges in the type libraries.

...

OK, thank you Georg.


> : I don't want client to continuously cause exceptions in my server, just 
> : because there is no way to let them know about the limits.
> 
> Use 'Valid and so on. Web services or not, I/O is always a possible
> source of surprises. :-)  A secure server cannot rely on external input
> anyway, I'd guess.

Clearly (although I also guess that most of the users will try to use 
the service, not to break it!)

But on the client side, I feel unconfortable not having those informations.
Let's look at the WSDL example in AWS documentation : the example uses a 
(real) service giving book prices.
The returned price is a Float. Should I expect 10 ** 59 dollars for a 
book? or 10 ** -13?

That's not a big problem, and I can understand that there is a deal 
between simplicity and power.
It's just that I feel better with
type Book_Price is delta 0.01 range 0 .. 1_000;

-- 
Lionel

Re: Experiences of XML parser generators for Ada?

[Lionel Draghi]

Lionel Draghi a ï¿œcrit :
...
> Yes, but
> 
>    type Money is range 1 .. 10;
> 
> becomes
> 
>    name="TN" type="xsd:int"
name="Money", sorry.

Re: Experiences of XML parser generators for Ada?

[Simon Wright]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:

> Yes, but
> 
>     type Money is range 1 .. 10;
> 
> becomes
> 
>     name="TN" type="xsd:int"
> 
> in WSDL. The range is lost.

I'm not familiar with this part of XML Schema, but it looks as though
you could say

<xsd:simpleType name="money">
  <xsd:restriction base="positiveInteger">
    <xsd:minInclusive value="1"/>
    <xsd:maxInclusive value="10"/>
  </xsd:restriction>
</xsd:simpleType>

(if you had the time to spare!)

-- 
Simon Wright                               100% Ada, no bugs.

Re: Experiences of XML parser generators for Ada?

[Lionel Draghi]

Simon Wright a ï¿œcrit :
...
>>    type Money is range 1 .. 10;
...
> I'm not familiar with this part of XML Schema, but it looks as though
> you could say
> 
> <xsd:simpleType name="money">
>   <xsd:restriction base="positiveInteger">
>     <xsd:minInclusive value="1"/>
>     <xsd:maxInclusive value="10"/>
>   </xsd:restriction>
> </xsd:simpleType>
OK. So I was wrong.

> (if you had the time to spare!)
Actually, I did not check the schema, because I don't intend to generate 
this by myself, or with one of those pretty tools available.
I just gave a look at a glance to ada2wsdl results.
ada2wsdl seems much more effective to me. But maybe it doesn't use the 
full WSDL semantics.

-- 
Lionel Draghi

Re: Experiences of XML parser generators for Ada?

[Pascal Obry]

Lionel Draghi <Lionel.nospam.Draghi@Ada-France.org> writes:

> > I'm not familiar with this part of XML Schema, but it looks as though
> > you could say
> > <xsd:simpleType name="money">
> >   <xsd:restriction base="positiveInteger">
> >     <xsd:minInclusive value="1"/>
> >     <xsd:maxInclusive value="10"/>
> >   </xsd:restriction>
> > </xsd:simpleType>
> OK. So I was wrong.

As you found out it is possible to specify ranges in the schema. Another
example is the character definition (strange enough there is no such type in
the WSDL standard, so you have to use a schema definition):

   <simpleType name="Character">
      <restriction base="xsd:string">
         <length value="1"/>
      </restriction>
   </simpleType>

So basically a string of length 1. This is exactly what ada2wsdl generates.

> Actually, I did not check the schema, because I don't intend to generate this
> by myself, or with one of those pretty tools available.
> I just gave a look at a glance to ada2wsdl results.
> ada2wsdl seems much more effective to me. But maybe it doesn't use the full
> WSDL semantics.

Right, at this point ada2wsdl does not check the bounds of the Ada type
definitions. So for whatever type that is based on integer it generates
a xsd:int. It would be possible to improve this, but I'm not sure it will be
very readable at the end... and I'm not sure those bounds will be checked on
the other side by Java/AXIS for example. Note that schemas have not been
designed for WSDL only. WSDL uses schemas to define some types but I have
never come across a WSDL document which had a very elaborated schema section.

It would also be nice to have the wsdl2aws tools properly handles those
bounds...

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