[
Lists Home |
Date Index |
Thread Index
]
On Mon, 27 Dec 2004 12:00:18 -0800, Daniela Florescu <dflorescu@mac.com> 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?
|
