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] XML-enabled databases, XQuery APIs

[ Lists Home | Date Index | Thread Index ]

I don't say it isn't desirable; just that it isn't 
likely to be done soon if ever.  My guess is that this is an 
area where database vendors intend to compete 
on features and performance, and that getting an 
internal representation that works well in all 
rdbms implementations is significant work.  Today, 
we map even integer types when we have multiple rdbms 
systems and a single client type.

My concern today is that there are going to be multiple 
client-side application binaries and their contents have to be moved 
in and out of hybrid-relational dbs that also have an xml binary 
datatype.  So where we had a pretty good run at collapsing the parser/syntax
into one durable solution, we are going to bifurcate 
madly and rapidly into ever more lobster traps.  Given 
that a major reason for going to an application binary is performance, 
it seems unlikely that a generic binary that savages that 
requirement for rendering applications will be acceptable, 
but I hope I'm wrong about that.</paranoia>  

Intuitively, it seems the 
best the binary WG can accomplish is to reduce and document 
the XML binarization techniques and at least, reduce the patent load. 
That last bit is a nice side effect of the ISO/W3DC efforts.

The US Navy has approved X3D as a standard.  Where 
lifecycle counts, the customer votes.   X3D has a draft 
for a binary encoding. The consortium's intent is to 
follow the W3C's lead but the binary will be a fact of 
the media type encodings because the customer demands it. 

Will the dbms customers demand something similar for dbms xml 
datatypes given that the dbms and middleware will be 
responsible for ensuring the client-side binaries are 


From: Ken North [mailto:kennorth@sbcglobal.net]

> The use of application binaries to get performance complicates things,
> and yet, we will have them.

Hmmm. There are benefits from standard binary formats such as JPEG and
MPEG-4 -- 
interoperability being the primary benefit.

Let's not be too quick to dismiss the benefits of having DBMS clients that
understand the binary representation used to store the data, and being able
communicate with the server using data in that format.

Secure client-server document exchange and encryption come to mind. If you
an application that mandates the secure exchange of documents between client
server, you're going to have to burn client cycles to encrypt/decrypt the
data.   There might also be a requirement the XML document or fragments be
stored in an encrypted form in the database.

If you're burning client cycles to encrypt, why not present the data to the
server in a form it can use?

Because you're operating in a secure document processing mode, you've
incurred the overhead of authorization and authentication. You're passing
from a trusted client to a trusted server, and vice-versa.


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

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