[
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.
<paranoia>
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
wavefront
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
supported?
len
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
to
communicate with the server using data in that format.
Secure client-server document exchange and encryption come to mind. If you
have
an application that mandates the secure exchange of documents between client
and
server, you're going to have to burn client cycles to encrypt/decrypt the
XML
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
already
incurred the overhead of authorization and authentication. You're passing
data
from a trusted client to a trusted server, and vice-versa.
|
