I have modified Pierre's code to get a file as input but when I run it
in CMUCL with (ext:run-program ""), it gets freezed and I'm unable to
get a stream from it whereas the program runs perfectly from bash (and
pipes)! :(

  You had a point?

I had two beers late last night, and had just one cup of coffee this
morning, so I'm qualified to reply.

When you get down to it, the tools for evaluating the cost of
operations in a CL implementation are more than adequate for
determining the real cost of an operation.  That said, not only do I
as a CL hacker understand the VALUES (remember this is CL so we can
have more than one) of everything, but I can determine the cost of an
operation or set of operations or a design decision quicker than C or
Java hackers.  Not only can I try out multiple approaches faster, but
my profiling, call recording, memeory monitoring, code stepping and
call statistics tools are boffo!

XML is a great example, lame ass programmerdweebz getting weak in the
knees at the thought of writing a parser see XML as their savior.
Then once they get that done they graduate to the net circle of hell,
err I mean level of competence, and suddenly since everyone has a
parser that understands their sin tax they figure that everything
shoudl be encoded in that and it would like make it all inter-operable
and be a great big synchronicity win!

So, for the VALUE of not writing a parser they incur billions of
dollars worth of marketing, re-engineering, training, support, and
mental health maintenance COSTS.

Ok, I lied, Ihad one cup of coffee last night and two beers this
morning.  Or was it three?  Damn, time to check the empy CAR and CDR
slots in my SIXPACK.  Look out world, I'm a drunk industrial CL
programmer here to improve your productivity apps!

Another memorable quote.

Is there anyone here with a requirement to /read/ legal but otherwise
unspecified XML? (ouch)

Is anyone aware of a standardized domain-specific XML representation
that is unreadable by an app to which the domain-specific XML
representation is known? (not)

These are /my/ sticking points in this discussion. I do not think I
could read arbitrary XML, nor do I think arbitrary XML is meant to be
readable. That's why folks in different domains are standardizing.
(hello?)

--

-dan, going forward

--

  I have some problem getting at your rhetorical style, but it seems that
  you are not arguing, only positing and stipulating.

  There are _many_ people who cannot generate valid (legal is something
  else :) XML if their life depends on it.  The problem is the moronic DTD
  and/or schema cruft.  Getting both of these right is a nightmare that the
  people who could have been trained for it do not want to do and those who
  do it are not trained to handle that kind of programmer-level design.

  XML _is_ readable without having a DTD and having a clue what the data
  "means" -- that was the primary design goal.  The problem with SGML was
  that you would not know whether some element had CDATA or RCDATA declared
  contents, meaning that only an end-tag would be recognized (and it better
  be for the only open element, in the spirit of redundant redundancy), not
  a start-tag for some other element, which would throw a naive parser off,
  as well as a lot of other minor stateful parsing problems.

  The parsability of arbitrary XML is such an obvious design goal of XML
  that I really wonder how you arrived at your last paragraph.  It is
  completely bogus as a rationale for standardizing elements and their
  structural relationship, too.  What people are standardizing in XML is
  the same they standardize with EDIFACT or systematized nomenclature for
  medicine (SNOMED) or even such "simple" things as the call letters of
  ships, airplanes, airports, radio and TV stations, etc.  People tend to
  want to standardize sematnics, and leave syntax to randomness.  XML is
  standardized randomness and might therefore be chosen as the preferred
  random way of expressing someone's semantic constructs.

I must be nuts, but there's a significant point that hasn't
been brought out. I've been using XML since the days of a
draft specification and am not blind to it's warts. Most
(all?) of the criticisms heaped upon it by others here are
quite correct.

The thing that has been lacking in the discussion is a
proper placement of the technology among alternative
techniques or approaches. For many of those who are using
XML, the only alternative they have is OLE structured
storage. That there are actually alternatives that they
just don't know about because they are ignorant is beside
the point. If they don't know about them or understand
them, these things aren't alternatives.

An XML DTD, as ugly as it is, or a schema is a miracle
of clarity and consistency in a world in which document
formats change when some VB programmer makes changes to
"code", saves the "code", undoes the changes, and saves
again.

You can argue that people shouldn't be using tools that
are that lame, and that people who can't write a proper
parser shouldn't be programming, but as right as you may
be they won't stop.

As bad as it is, XML allows many projects to succeed that
would otherwise fail in a dustcloud of partially broken
or imcompatible parsers, ever-shifting formats resulting
in mis-understood hacks at the wrong layer, etc. It might
have the additional benefit that for a few souls, it is
the beginning of a more serious understanding of data
representation.

Sorry for the intrusion,

In CMU CL, something like this should work:

(defun parse-xml-from-file (file)
  (let* ((process (ext:run-program *xml-expat-parser-path* nil
                                   :input file :output :stream :wait nil))
         (output (ext:process-output process)))
    (unwind-protect
        (read output)
      (ext:process-wait process)
      (ext:process-close process)
      (unless (zerop (ext:process-exit-code process))
        (error "Error parsing XML file ~A." file)))))

If you modified elements.c to take a filename argument, you'd do

  (let* ((process (ext:run-program *xml-expat-parser-path* (list file)
                                   :input nil :output :stream :wait nil))

instead.

Regs, Pierre.

Regs, Pierre.

i think I am lucky, we just have to generate XML and provide XSL to
convert our own XML to other formats, not read arbitrary XML (for now).
But I still hark back to memories of code I have seen which was a pure
horror, written in a language which could have been used to write
elegant code. Actually all languages fit that description...including
XML.

Are y'all lookin for a language in which one cannot write bad code?

  I am still not sure what you are referring to, but the main difference
  between SGML and XML is precisely that you do not need the DTD to parse
  an XML "document".

| Are y'all lookin for a language in which one cannot write bad code?

  No, just a language that has static style checking and does not stop at
  proven correctness, but requires proven good taste.  This would take care
  of a lot more real-life problems than, e.g., static type checking.

  Really, i just want every single professional programmer to be competent.
  (The difference between a hobbyist and a professional programmer should
  have been accountability.  The difference today is whether he gets paid.)

Lets not forget that Lisp has so far survived for more than 4 decades,
allthough having been announced dead and nearly extinct numerous
times.

I am personally of the firm belief (probably to be taking in the
religious sense) that eventually Lisp programmers will be dancing on
the grave of Java. It won't happen anytime soon, but I am prepared to
wait :-)

different kettles of fish entirely.

Even without a DTD you can see that "<m><g>Hello</g></m>"
is "Hello" inside a "g" inside an "m".  That's parsing
and it's (relatively) easy.

With a DTD you can answer questions like "is a 'g' allowed
inside an 'm', and if so, can we have text inside the 'g'?"
That's still parsing, but not so easy.

<form>
(if (...condition...)
    (...then...)
  (...else...))
</form>

which would help cut down on the sugar intake.

  :D  Good one!  Yes, it is certainly possible to defer the whole problem
  to what SGML and XML call "notations", but the intention with notations
  was actually that they should have parsers that return structured objects.

  I doubt that anyone uses notations this way with the current crop of
  parsers, however.  If someone knows, I would be happy to hear otherwise.