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


Hi Andrew:

At 05:17 PM 9/20/00 EDT, you wrote:

>I doubt that the authors of the XML 1.0 Recommendation thought of an XML 
>processor in the diffuse way that you refer to. 

Probably not. They were concerned, naturally enough (since they were
defining XML's notation), with the behavior of that type of processor I am
designating a "parser." The existence of "XML processors" that would not
even have the capability of parsing (such as some XSLT processors can be),
may have been little anticipated by them. It would be interesting to know.
(Maybe I'll ask when I have a good chance -- or maybe someone closer to the
action could give a perspective.)

>The XML 1.0 Recommendation can be viewed as a description of how an XML 
>processor is required to behave, assuming it is conforming.

I don't believe that most users of the term "XML processor" have the XML
Rec itself precisely in mind. That doesn't mean their use of the term is
illegitimate.

>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.

Agreed, and the critter it calls a "processor" is what I'd relegate to the
more precise term "parser" (since the type of processing it describes is
limited to parsing and validating XML notation).

>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.

My rationale is that the distinction is useful, it reflects what is coming
to be common parlance (because of its usefulness) in the world of XML, a
world that was not perfectly anticipated by the authors of the spec (as I
think they'd be willing to acknowledge).

I account for the seamless movement you note by maintaining that the spec
does not anticipate, and does not observe, the distinction I make. If they
had only said "parser," then my argument would be easier, and the term
"processor" would be free and clear for describing that class of software
that handles XML (XML-a-data-model), but which may delegate the work of
parsing to another processor (if it happens at all). It would be
interesting, it's true, to unearth any discussions they had about whether
"parser" or "processor" was a better term for their purposes, and why.
Maybe that discussion would suggest other distinctions or other solutions
to this particular semantic knot.

>It is always interesting to discuss such issues, to try to determine what
the 
>authors of the specification intended.

Sure, but that's not the most interesting part to me. I am as interested in
how language can change and adapt to be more precise and more useful as the
world changes, as I am in speculating on what someone "intended."

I guess I take the original question differently from you. When Ben posted
the query, 

>I have recently become confused between the difference of XSLT and actual 
>XSL.  I also have not been able to ratianalize the difference between a 
>parser and a processor... does anyone know of a page or source of 
>information to shed light on this?

I took the question to be much more open-ended than merely a speculation on
what the authors of the XML Rec intended. It is the language of the Rec,
not the unfathomable intentions of its writers, that is normative -- and
it's only normative with respect to issues it addresses. (In fact, I
believe the authors of the spec were very aware of this limitation, that
their intentions ultimately mattered only as they were expressed by their
rhetorical action, but didn't matter much in themselves: how's *that* for
speculating on intention? :-)

The XML Rec doesn't speak to the question of parser vs. processor at all --
and yet, I do believe there's a meaningful distinction to be made. If we
stick literally to the XML Rec, a "processor" must always be a "parser" in
my sense -- but what then, is an XSLT processor that works directly on a
DOM tree held in an object db? Is it not an "XML Processor"? Is there a
term we could convince the world to use instead?

Fun. Regards,
Wendell


======================================================================
Wendell Piez                            mailto:wapiez@mulberrytech.com
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
======================================================================


 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]