Subject: RE: XSL vs. XSLT and processors vs. parsers From: "Evan Lenz" <elenz@xxxxxxxxxxx> Date: Wed, 20 Sep 2000 16:41:45 -0700 |
The battle seems to be between "original intent" and "what makes the most sense." But guess what, neither has ultimate control over meaning. Each of the following statements are true: An XML processor and an XML parser are the same thing. An XML processor and an XML parser are not the same thing. An XML parser parses the physical XML document, passing information up to the application. An XML processor parses the physical XML document, passing information up to the application. An XML processor is an application that receives information passed up from the XML parser. (the converse of this is probably *not* true; I'm not a complete relativist) In conclusion, while the Academy of Ancient Music plays beautifully, I don't believe it's because they've managed to recreate the intent for which and setting within which Bach composed his music. Evan Lenz elenz@xxxxxxxxxxx http://www.xyzfind.com XYZFind Corp. "Building Better Search" Download our free beta software: http://www.xyzfind.com/beta -----Original Message----- From: owner-xsl-list@xxxxxxxxxxxxxxxx [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of AndrewWatt2000@xxxxxxx Sent: Wednesday, September 20, 2000 2:18 PM To: xsl-list@xxxxxxxxxxxxxxxx Subject: Re: XSL vs. XSLT and processors vs. parsers In a message dated 20/09/00 21:32:30 GMT Daylight Time, wapiez@xxxxxxxxxxxxxxxx writes: > An "XML processor" is a software program that does something with XML > documents. These documents may be input to the program either as static > entities in the notation described in the XML Recommendation (that is, > files using tags following the XML definition of "well-formed"), or more > generally, as "documents" constructed through some other method (for > example, presented by some other application as a pre-built DOM tree, or > fired as a series of SAX events). Accordingly, the term "XML Processor" is > somewhat loose with respect to its input, and wide open with respect to its > operations or output. Wendell, Thanks for the response. I doubt that the authors of the XML 1.0 Recommendation thought of an XML processor in the diffuse way that you refer to. The XML 1.0 Recommendation can be viewed as a description of how an XML processor is required to behave, assuming it is conforming. For example, in Section 1 it is stated, "This specification describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application.". In Section 5.1 of the XML 1.0 Recommendation, for example, there is a reference to validating and non-validating conforming XML processors. The XML 1.0 Recommendation describes how a conforming XML processor must behave as well as describing behaviour which is optional. > Perhaps the real savants on this list will weigh in if I've misstated > anything. Note that this take on it differs from what Andrew Watt said on > this list (an XML processor and XML parser are "one and the same"). I am > making a distinction between them, related to a distinction I am making > between software that does something with XML-the-notation (a processor > which must be or contain a parser), and software that does something with > XML-a-data-model (a processor which does not necessarily have a parser, > like an XSLT processor, though it may sit downstream from one). > > Cheers, > Wendell Wendell, I guess I am excluded by implication from the category of "real savant". <grin> The XML 1.0 Recommendation has a lot to say about the behaviour of a conforming XML processor. If after reviewing the usage of the term "XML processor" in the XML 1.0 Recommendation you still want to argue that there is a distinction between an XML processor and an XML parser then I would be interested in your rationale. Perhaps you could also account for the seamless movement of reference to "processor" to "parser" in Appendix E of the Recommendation. It is always interesting to discuss such issues, to try to determine what the authors of the specification intended. Andrew Watt XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL vs. XSLT and processors vs., Wendell Piez | Thread | trimming xml output by number of ch, Matthew Haughey |
RE: XSLT enhancement requests, Evan Lenz | Date | RE: Rendering: filling tag attribut, Michael Strasser |
Month |