Sterling, At 22:20 2-10-2002, Sterling Hughes wrote:
>http://www.bumblebury.com/phptodo/xmsl.html > >my thoughts on the matter... If you really want to handle XML, XSLT and >the like in PHP, the solution is to build a standardized, documented, >DOM, SAX, XPath, XInclude, XPointer interface, and then have functions >which wrap around these to apply XSLT transformations. I've given this some thought. And while you're right that it would be the best option, I don't see it happen any time soon, because: -- this would then make it core, same as mbstring -- domxml module already has an audience and is well maintained -- the libxml/libxslt libraries are quite a moving target. -- not enough people/knowledge to handle it. Further more - this would make the implementation for another backend quite difficult and possibly slow - would you then drop the libxml/libxlt interaction, or does - despite the other backend - libxml/libxslt still handle the abstraction. Also, these libraries would add up to the download size (minor). I think the approach you've made so far, is the right one, which I'd like to extend further, with the following outlines in mind: -- Abstract x* standards and provide a default backend, which is a lightweight, straight forward approach. These modules should by default be procedural. -- Leave domxml where it is -> it is a feature-rich alternative, for people who want an object oriented interface and want to be in sync with the latest standards. -- Add DOM support on ext/xml using the Sablotron SXP interfaces. This extension is now based on expat (which will continue to be so, for existing functions), but it lacks the document creation functions. It only allows for parsing. We could also move ext/xml to ext/xml-parser but I don't think it's a good idea. IMO it will not compete with DomXML, simply because it's procedural and will have a minimal set of functions. Further more, it will be aimed at what's "known to work" and therefore lag behind published recomendations. Think "Opera" vs. "Mozilla" if you like. Last but not least, the created documents can be passed to ext/xslt for fur- ther processing, without any dump-2-string construct. -- Add ext/xpath. I'm not entirely sure, that it deserves an extension, since it's not really a programming language you can use, without using other parts of the xml family. It's nice to run an xpath query on any given string, but that's probably all that it's good for. It would make an xml-based stream-filter very easy though. For instance a 'syslog' module, which distributes the xml-based log events by quering the header. However - looking at XPath 2.0WD there are a lot more interesting things, that can warrant an extension. -- Add further extension for things like xmlsig and xml encryption, which would make secure interaction possible. These would need libraries that are specific for the task, or coded from scratch if there isn't one suitably available. All of the above is aimed at 4.4/5.0 whichever comes first. PS. Not sure what to do with XMl-Schema - it's sortof more an 'internal' of many XML dialects. It could be abstracted, but not sure what to do with it, other than 'xmlschema_validate()'. PS2: Feel free to move this to /dev/fuckoff if you feel that way :-) Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
