[EMAIL PROTECTED] 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
implementations),
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
ask...
Thanks!
Army
