[
Lists Home |
Date Index |
Thread Index
]
On 4/18/05, Bullard, Claude L (Len) <len.bullard@intergraph.com> wrote:
> Ok. If a generalized binary is the
> most ineffective, how can the XML datatype in
> Yukon rely on a single binary itself?
As I understand it, SQL server's internal format is designed to meet
the needs of the XQuery implementation, and certainly not efficient
transport over low-bandwidth channels, high-speed SOAP header
processing, or any of the other documented use cases for binary XML.
Thus, a standard optimized for wireless is probably not going to help
XQuery DBs much, and a standard optimized for XQuery probably wouldn't
do the wireless industry much good.
> Is it the
> case for XML binaries that the sweet spot is in
> the systems that rely on a schema so while the
> case for well-formed-only binarization is weak,
> the case for valid binaries is stronger?
It's easy to compress schema-valid XML because both sides know the
vocabulary, so the tags can be tokenized; if the structure is rigid,
you don't have to send the markup at all. Of course, calling that
"XML" in any form is a big stretch. I think it is true that the
statistics for compression and parsing speedup for well-formed XML are
considerably less impressive -- you have to send the tags around
somehow, and you either have to have some out-of-band agreement on
tokens or structure indexes, or you have to spend processing power on
computing them and putting that information in the instance.
>
>
> IOW, there is no familial relationship among application
> binaries and the dbms binaries, and furthermore, no good
> reason to standardize the dbms binaries?
That's our position.
>
> An X3D file can show up as an X3D binary (an ISO
> encoding for X3D, thus an application binary). If I
> want to store that in a Yukon XML datatype, what
> do I do with it? Parse it out of that format into ?
> to then push it into the Yukon XML datatype?
The "Yukon XML datatype", as far as the outside world is concerned, is
XML 1.0. One doesn't talk about the "Xerces DOM datatype" or the
"Saxon XSLT datatype", although of course they also have internal data
structures support the work of implementing the standards. One could
exchange binary serializations of any of these things, probably
getting more performance, but at a rather heavy cost in
interoperability.
>
> So on the client side, I never want to pull a big
> lump of XML to the client and query it there? Or,
> in cases where I am querying it, I am doing it
> inside the application and XQuery is overkill for
> that?
I would say "Use XQuery in the DB to pull out a small lump of XML and
process it with your tool of choice on the client." Let the DB do the
heavy lifting, then XSLT, SAX, DOM, or some other tool can work with
the XML in a developer-friendly way without worrying too much about
performance. Maybe in a few years it will be obvious that everyone
has similar internal formats and that real efficiencies would be
achieved by standardizing the binary format exchanged from the DB to
the API ... or maybe everyone will optimize for their most lucrative
business cases and standardization will never be feasible. We shall
see, but it is WAY premature now to even guess, IMHO.
>
> I am confused. I thought the concept of loose coupling
> depending on grabbing as big a chunk of XML as is practical
> given asynchronicity and dependencies, pulling it to the
> client, and operating on it there. You seem to say that
> XQuery is overkill for that and XPath is sweet.
Loose coupling is just one factor that has to be considered.
Well-formed XML supports loose coupling, but of course there are costs
associated with that, e.g. processing performance and network
bandwidth. A binary format that essentially serializes an application
data structure could be faster and smaller than XML, but wouldn't have
its loose coupling. Binary XML tries to find a sweet spot in the
middle; we shall see if it succeeds.
So, yes I see XQuery as a power tool to do the heavy lifting on the
server side. It logically could be applied on the client, but I think
that something more at the functionality point of XPath, with the
native environment's data types rather than the XQuery datatypes, hits
a much sweeter spot than XQuery does when it comes to actually being
used by programmers. We shall see, of course.
|
