XML Component API

[Tyler Baker]

Oren Ben-Kiki wrote:

> I raised the question of a standard API to XSL processors in the XSL mailing
> list. This question has quickly touched on general issues of how to combine
> XML processing modules, since there are two incompatible ways to pass XML
> data - as an in-memory DOM tree or as "parsing" events.
>
> I came up with the attached scheme. It allows writing all sorts of XML
> related components, using either of the APIs, and still easily combine them
> together to obtain complex XML processing goals, with little or no loss of
> efficiency.
>

This looks like it has a lot of different things in here which may or may not be
directly applicable to an XSL Processor, nevertheless it is a good start and by
the looks of things it seems that you have obviously put some time and thought
into this.  I am sure everyone here appreciates your comments as well as your
efforts to date on the xsl-list, so please keep up the good work.

On the SAX issue, SAX may or may not be updated soon.  I guess a lot of this
depends on David's plans (if he has any) as to whether he will donate more of
his already much appreciated time to SAX, or else pass the torch to someone
else.  I am not so sure we should update SAX to support the latest namespaces
spec so fast.  I would like to see if some person or group could come up with a
namespaces solution in the near future (or at least generate public debate) that
generates more concensus among the XML developer community than the recent W3C
recommendation "Namespaces in XML".  I am not happy with "Namespaces in XML" and
would prefer an alternative, even though at this point in time I don't think
namespaces are all too important for the tasks people are acutally using XML
for.

With respect to namespaces, I think SAX should be updated on the following
conditions:

(1) If there is little or no interest in the developer community for using
namespaces (whatever mechanism there is) to begin with, then SAX should not be
updated with something that the great majority of the developer community deems
as a de-facto useless issue.

(2) If there is interest in the developer community for using namespaces, but
that there is a good solid majority who believe SAX needs a namespaces
alternative to "Namespaces in XML", then maybe someone here who is disappointed
in "Namespaces in XML" and has a better idea could take up the lead on this
issue.  When and if this alternative is produced, then update SAX with this
alternative

(3) If there is interest in the developer community for using namespaces, and
there is not as much angst over "Namespaces in XML" as a lot of people
(including myself) feel there is, or else no one proposes an alternative that is
better than "Namespaces in XML" then update the SAX spec to support the W3C
recommendation.

Lets not update SAX too hastily on this particular namepsaces issue when there
appears to be little concensus on the namespaces issue among the developer
community to begin with.  Just because the W3C proposes something, does not mean
us developers are forced to support it.  Being able to say your XML Parser is
"Namespaces compliant" may win marketing points among some less than
knowledgeable XML developers, but the truth is unless people actually use this
feature, it is nothing more than additional code bloat.

Regards,

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)