OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath 1.5? (was RE: [xml-dev] typing and markup)

[ Lists Home | Date Index | Thread Index ]

At 08:05 PM 5/7/2002 -0400, Thomas B. Passin wrote:
>[Jonathan Robie]
>To: "Thomas B. Passin" <tpassin@comcast.net>; <xml-dev@lists.xml.org>
>Sent: Tuesday, May 07, 2002 12:14 PM
>Subject: Re: [xml-dev] XPath 1.5? (was RE: [xml-dev] typing and markup)
> > In fact, datatypes are optional in XML schema, static typing will probably
> > be optional in XQuery (there is a note in the XQuery document to that
> > effect), and the operators of XQuery and XPath are all defined for untyped
> > data as well as for typed data. I think that we have put a *lot* of work
> > into making sure that our type system scales to typed data, untyped data,
> > and mixtures of the two.

>Yup, I've been clear about this, and I appreciate the work that has gone
>into it, especially since I personally anticipate using XQuery mainly for
>schema-less data.  I was addressing remarks in some posts to the effect that
>the extra machinery to handle PSVI and types would make processors bloated
>and slow.  If that were correct, it might be useful to have that machinery
>in an optional layer.  If it's not correct, there's no such issue.

This is going to depend to some degree on your implementation strategy, so 
everything I say here comes from my understanding of a few implementations.

Static analysis never costs anything at run time. Static analysis can also 
be used to rewrite code to be more efficient at run time. So static typing, 
the typing people seem to be complaining about the most, never degrades 
performance, and often helps performance.

Dynamic typing has a more direct influence on run time performance. For any 
system that actually stores typed data, including relational databases and 
those native XML databases that use XML Schema, representing typed data 
directly in the XML view is probably less overhead at run time. If you are 
going to use data with typed operations such as arithmetic operations, then 
an untyped approach means you need a run-time cast, which is not needed if 
your data is typed. A system that knows the datatypes associated with data 
can use that information to optimize the way it is stored and used.

So I would like to understand more about the claim that using typed data 
makes query processors slow and bloated. Perhaps the people making these 
claims have implementation experience that will bring light on this claim, 
or can sketch out the rough details of an architecture and the impact that 
types would have on this architecture.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS