Return-Path: Delivered-To: apmail-xml-cocoon-docs-archive@xml.apache.org Received: (qmail 12103 invoked by uid 500); 21 Feb 2003 14:00:06 -0000 Mailing-List: contact cocoon-docs-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-docs@xml.apache.org Delivered-To: mailing list cocoon-docs@xml.apache.org Received: (qmail 12002 invoked from network); 21 Feb 2003 14:00:04 -0000 Received: from dobit2.rug.ac.be (157.193.42.8) by daedalus.apache.org with SMTP; 21 Feb 2003 14:00:04 -0000 Received: from allserv.rug.ac.be (allserv.rug.ac.be [157.193.40.42]) by dobit2.rug.ac.be (8.11.1/8.11.1) with ESMTP id h1LE03d17348 for ; Fri, 21 Feb 2003 15:00:04 +0100 (MET) Received: from otsrv1.iic.rug.ac.be (otsrv1.iic.rug.ac.be [157.193.121.51]) by allserv.rug.ac.be (8.11.1/8.11.1) with ESMTP id h1LE03B12377 for ; Fri, 21 Feb 2003 15:00:03 +0100 (MET) Received: from otsrv1.iic.rug.ac.be (localhost [127.0.0.1]) by otsrv1.iic.rug.ac.be (8.11.6/8.11.6) with ESMTP id h1LE03501226 for ; Fri, 21 Feb 2003 15:00:03 +0100 Date: Fri, 21 Feb 2003 15:00:03 +0100 Message-Id: <200302211400.h1LE03501226@otsrv1.iic.rug.ac.be> From: stevenn@outerthought.org To: cocoon-docs@xml.apache.org Subject: [WIKI-UPDATE] SAX Fri Feb 21 15:00:03 2003 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Page: http://wiki.cocoondev.org/Wiki.jsp?page=SAX , version: 13 on Fri Feb 21 13:13:53 2003 by SylvainWallez - Some people thought "That's inconvenient! Why can't we handle the document in a sequential manner instead?". So they invented (particulary a guy named David Meggison invented) SAX, the __S__imple (or "Streaming") __A__pi (for) __X__mldocuments. ? ^^ + Some people thought "That's inconvenient! Why can't we handle the document in a sequential manner instead?". So they invented (particulary a guy named David Meggison invented) SAX, the __S__imple (or "Streaming") __A__pi (for) __X__ML documents. ? ^^^ - The pipeline starts with a Generator that knows how to read __something__ (for example an XML document) and from that generate a stream of SAX events ("document begins" etc). Then there might be a bunch of other components that modifies the stream of SAX events, for instance using XSLT or some other transforming algorithm. + The pipeline starts with a Generator that knows how to compute or read __something__ (for example parsing an XML document) and from that generate a stream of SAX events ("document begins" etc). Then there might be a bunch of other components that modifies the stream of SAX events, for instance using XSLT or some other transforming algorithm. ? +++++++++++ ++++++++ - In the end there is the Serializer that listens to the SAXEvents and translates them to normal text. + In the end there is the Serializer that listens to the SAX events and translates them to a binary data stream. This transformation to binary data can be as simple as "translating" SAX events to text (the usual form of an XML document), or as complex as producing PDF from XSL:FO or a JPEG image from SVG. - When the XMLGenerator looks at an XML file and sees "" it fires the SAXEvent "element 'doc' begins". ? ^ + When the XMLGenerator looks at an XML file and sees "" it fires the SAX event "element 'doc' begins". ? ^^ - A Transformer might take it from here, perhaps instructed to transform every "" element into a "" element. So when this Transformer recieves the "element 'doc' begins", it fires the SAXEvent "element 'document' begins". ? ^ + A Transformer might take it from here, perhaps instructed to transform every "" element into a "" element. So when this Transformer recieves the "element 'doc' begins", it fires the SAX event "element 'document' begins". ? ^^ - In the other end of the pipeline, when the serializer recieves the SAXEvent "element 'document' begins", it converts it to the text "". ? ^ + In the other end of the pipeline, when the serializer recieves the SAX event "element 'document' begins", it converts it to the text "". ? ^^