xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Proposal for addiction to the Sun XML Java API
Date Fri, 26 Nov 1999 17:56:03 GMT

I evaluated the proposed XML Java API and it looks like a very nice
proposal. James already received my personal comments about what's
already inside, but nothing should change that much since mostly SAX and
DOM are there, plus a couple of unitility classes to allow platform
indipendent creation of SAX and DOM parsers.

One thing I see it's the lack of output support: the API is
"input-biased", in the sense that allows you to _read_ XML. For writing,
you're on your own.

I find this lack of symmetry frustrating in both the SAX API and in the
XML Java API, not only because it results in a huge effort duplication,
but because those methods are so basic that it's incredible they were
not placed inside the SAX API from start.

Moreover, now that XSLT has standardized the idea of "output handling"
to "serialize" the DOM into streams of chars or bytes, it results almost
crutial to support this basic type of functionality in a very solid

In the future, we have plans for SVG->JPG serialization as well as, who
knows, stuff like VoiceML->WAV and so on.

An output handler identifies the couple (XML doctypes, output file
format) and XSLT defines three output handlers: "XML", "HTML" and "text"
which represent
 XML -> (All XML doctypes, XML)
 text -> (text, text)

Note that

 text -> (text, text)

means that the "text" output handler, takes unstructured text from
memory and serializes it as unstructured text.

other and more specific (and complex) output handlers could be

 JPG-resterize -> (SVG, JPG)
 PNG-rasterize -> (SVG, PNG)
 Speech-synthesis -> (VML, WAV)
 VRML-Rendering -> (X3D, JPG)

Note, for example, that serializers should deal only with "final"
doctypes, final in the sense that no further styling is needed to
contain all the required rendering information.

In fact an output handler like

 Music-printer -> (MusicML, PDF)

should be decomposed into a chain like

 MusicML -(XSLT)-> FO+SVG -(FOP)-> PDF

where a graphic stylesheet should transform the MusicML file into final

In conclusion, I think the XML Java API should allow at least to build
the unit filter for XML

  file -> parser -> serializer -> file

keeping in mind that while you need just one parser in the system, you
can have more serializers instanced at the same time (think about Cocoon
that is able to format the output depending on client request).

What do you think?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche

View raw message