To refine on Mike's points:
At 05:46 PM 3/20/01, he wrote:
>"M. Farhan" wrote:
> > 1 . Can we call SAX and DOM as XML Parsers??? or they are interfaces
> > to access the XML document.
> > 2. if we have XSLT to handle the xml documents...so why do we use DOM
> > and SAX...whats the idea...please clarify the idea??
> > Thanks in advance..
>The system is layered:
>XSLT depends on SAX or DOM. Most XSLT Processors depend on a DOM
>implementation, since they don't yet handle the event-based SAX model.
Sort of. XSLT requires access to the entire tree, so it can be implemented
on top of DOM. Many XSLT processors started this way. But DOM is a bit
heavyweight for their internal requirements, so many have moved to a
lighter-weight internal data model/API.
Providing XSLT, as a solution, fits your problem well, you can use XSLT
quite happily without concerning yourself at all with SAX or DOM. It's all
under the hood. If you need to enhance/extend XSLT, you may have to get
down to this low-level stuff.
>SAX: creates "events" for parts of the document. You may respond to
>these events. It is "asynchronous" (sort-of) in the sense that you react
>to a callback from the SAX system. The xml document is read as a stream.
This is why SAX by itself isn't really up to the job of supporting XSLT,
whose data model (implied by the XPath spec) requires synchronous "random
access" to the document.
>DOM: The DOM library reads the whole document in, and plops a big tree
>in your lap.
>I think, technically, SAX and DOM are not parsers, they merely implement
>a particular way of accessing a document. For instance, a library may be
>written to "emit" SAX events, *as if* they came from the parsing of a
>document, but these events may be dynamically produced. That said, SAX
>is pretty close to the bone of a parser and they are often implemented
>as one library.
Correct. Both SAX and DOM are low-level APIs to a document. SAX is
lower-level than DOM, and in fact a parser that supports DOM may well build
its tree out of a SAX event stream. Application developers writing
procedural code may need to work with them or something like them (you can
always design your own API; nothing about XML requires support of either
SAX or DOM). But if you're working solely at the declarative level (such as
writing XSLT stylesheets/transforms) you can generally remain happily
ignorant of their mechanics.
Wendell Piez mailto:[log in to unmask]
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML