Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Component API
 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
