[
Lists Home |
Date Index |
Thread Index
]
At 03:35 PM 12/26/2001 -0500, Champion, Mike wrote:
>I for one would like to see someone elaborate on these points, and relate
>them back to the original question more clearly: How is XPath's lack of
>strong typing or functions going to cost anybody money in the next couple of
>years?
[ I am attempting to be on vacation, so I may not be very involved until
January ]
If you don't have strong typing, then you have programming errors that
could have been caught by the type system. That costs people money.
If you don't have functions, then it is hard to reuse code, so you have to
write each query again from scratch. That costs money. Functions are
particularly helpful together with function libraries. For instance, I have
written a function library for RDF and a function library for Topic Maps,
and they significantly simplify queries against these data sources. Sure, I
could write every query without functions, but I could also write any Java
program without using function libraries -- much of everyday programming
involves calling functions rather than writing equivalent code from scratch
each time.
If you write function libraries, and you can type check the library before
shipping, then you can guarantee that certain classes of errors will never
occur no matter what the data is, provided the data corresponds to the
schema for which the library was written. There's a reason that generations
of C and C++ programmers used lint - and in fact, there were many
businesses who required C and C++ programs to pass lint before they could
be deployed.
Also, knowledge about the types in a schema can be helpful for optimization.
>Is the difficulty of syntax-level XPath optimization (transforming a
>query expression into an equivalent expression that can be executed more
>efficiently) a significant cost factor for real businesses?
Real businesses do seem to care about the time needed to process a query or
to run a program.
>I accept the desireability of XQuery being a language that can query an XML
>view of relations, objects, and XML documents/data in a consistent manner.
>In the long run, a unified notion of "types" has to be developed that
>transcends all three.
Actually, I think that the unified notion of types should be defined purely
in terms of XML, but it should also be defined formally. That makes it
possible for people to relate the formal semantics of queries on XML to the
formal semantics of other systems, such as relational databases or objects.
A type system is not something you can bold on after the fact -- it has to
be the basis of the language.
>What I don't see is a compelling BUSINESS case for
>prioritizing this above a simple update syntax along the lines of the simple
>SQL examples that people always cite as what they want to do with XQuery.
>What am I missing here?
I think that the business case involves the ability to write programs with
fewer errors, reuse code, write maintainable libraries.
And all of this becomes even more important if a product supports updates,
because users can lose their data if they make mistakes that the system
should have caught for them via the type system.
Jonathan
|
