This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: XSL vs. XSLT and processors vs. parsers



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@xyzfind.com
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@mulberrytech.com
[mailto:owner-xsl-list@mulberrytech.com]On Behalf Of
AndrewWatt2000@aol.com
Sent: Wednesday, September 20, 2000 2:18 PM
To: xsl-list@mulberrytech.com
Subject: Re: XSL vs. XSLT and processors vs. parsers


In a message dated 20/09/00 21:32:30 GMT Daylight Time,
wapiez@mulberrytech.com 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]