Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Streaming XML (WAS: More on taming SAX (was Re:
 On Mon, 27 Dec 2004 12:00:18 -0800, Daniela Florescu <dflorescu@m...> wrote: > > I've thought about using an XPath tracker in error reporting to > > my library, which would be very simple to add at this point, and > Could you guys please try to clarify for me the answer to the following > question: instead > hand coding steaming applications using SAX, couldn't you write some > XQuery code (with external functions probably) to do the same thing ? > Did you try at least ? Did you try and fail ? If yes, why did it fail ? I'll take a stab at it. First, how many such streaming XQuery implementations are there for people to experiement with? BEA's comes to mind.... no others show up on a quick Googling. I'll bet that not many people are going to hassle with installing WebLogic just in order to play with XQuery. Second, Even if they did and loved it, how many could use it in their target environments? The whole point of standardization is platform and vendor *neutrality*, so a solution that is for all practical purposes platform and vendor-specific doesn't help. Until XQuery is a final Recommendation and widely supported on popular target platforms, I don't think that many people would move away from something as pervasive as SAX just because XQuery makes their job a bit easier, > > My hope is that at a certain point people will stop writing low level > code, and they'll rely on good implementations of XQuery to do the right amount of > streaming, in the > optimal way. That should be vendor's problem, not user's problem. Maybe someday, when/if XQuery becomes a de-facto standard in the real world (irrespective of its W3C Recommendation status) and vendors compete on the conformance and performance of their implementations. That's not the world we live in today; now the users have to worry about things that are not well-understood or standardized, such as the subset of XPath that can be easily/efficiently applied to data streams as opposed to indexed stores. I'm not sure how that will ever change; for example, people are still fiddling with their SQL code and table organizations to get optimal performance rather than simply trusting the implementations. Why will that be different for XPath/XQuery? But more generally, consider the conditions under which people adopt new technologies. Just thnking of the first few well-known hypotheses that come to mind, Tim Bray argues that hitting the 80/20 point is a necessary condition. Clayton Christensen argues something similar, that "disruptive" technologies must be good enough for the needs of a large mass of users *and* be dramatically cheaper/simpler than the established technologies. Metcalfe talks about those technologies whose value to any one user increases exponentially with the number of other users with which one interoperates. None of these apply to XQuery-as-a-programming-language: - As tedious as SAX is for the typical applications-level programmer, the spec itself is relatively simple. Maybe someday XQuery will disrupt it by providing so much infrastructure that the tedium isn't needed, but that's not today. - Some very large portion of the niche that XQuery as a middleware language (as opposed to XQuery as an XML Query Language) might conceiveably fill is already occupied by XSLT. XQuery not only has to disrupt "hand-coded" code, it has to displace XSLT in the mindshare of geeks. So far it looks to be losing that particular battle. - It's not obvious to me how a network effect for XQuery could emerge. It's not like HTTP/HTML or XML, which are all about interoperability; XQuery is essentially a software development approach that may give a single user an advantage over others, not a data interchange approach that creates value for users as a whole. XQuery has a real-world value proposition as a query language for XML content, whether it be in a specialized XML DB or an XML type in an RDBMS. Few disagree. It's not at all clear, however, that it has a compelling value in the middle tier as a replacement for SAX/DOM calls from a procedural language, or for XSLT as a non-procedural alternative. The arguments about how XQuery could *theoretically* fit into the middle tier and how *someday* the impelementations will be robust enough so that developers can trust performance to them are logical and plausible. Still, II suspect that people will need to see actual success stories before making that bet. Anyone have any to share? 
|
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
|
|||||||||
