db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject Re: Little adv. XML support
Date Sun, 26 Jun 2005 22:17:04 GMT
medvjed@centrum.cz wrote:
> thanks for your quick reply and your advices. About the implementation ID, 
> i think it should be the property of the XML table column. I mean when you 
> create a table with XML type column, you should (some way) specify the 
> storahe type you want to use. What do you think about it? (i can see maybe 
> some problem when querying 2 differnt XML type at one select, but maybe it 
> could be done). 

Hi Petr,

I don't think we want the user to know anything about the different XML storage 
implementations.  All they should see is a single XML datatype with 
corresponding functions, based on the behavior defined by the SQL/XML standard 
(remember, one of the primary goals of Derby is to be a standards-based database).

Just like with other Derby datatypes, the user shouldn't have to know _how_ any 
specific datatype is implemented--all the user does is specify the type and then 
it's up to Derby to decide how it wants to do things.  Not only does that make 
it easier for the user (s/he doesn't have to try to decide between two or more 
implementations), but it means that we can change/enhance our XML implementation 
without the user having to change any of his/her applications--they will get the 
enhanced implementations for free with an upgraded database.

The assumption here is that new XML implementations (such as yours) will have 
advantages over the old one(s).  If that's the case (and it should be, or else 
why are we adding the implementation to begin with? ;), then Derby should always 
use the newest implementation when it can.  But at the same time, if it's 
dealing with older XML data (i.e. XML that was stored using an older 
implementation) it should be able to handle that, as well.

So in brief, we want to keep the different XML storage implementations internal 
to Derby (that is, we do _not_ want to expose them to the user) because by doing 
so, we make XML:

1) simpler for the user (s/he doesn't have to know anything about storage 
2) portable (a single user application can be used from one version of Derby to 
the next without any changes to the app code),
3) standards-compliant (based on SQL/XML standards)

I hope all of that makes sense, but if you have any further questions, please do 


View raw message