[
Lists Home |
Date Index |
Thread Index
]
Ok. If a generalized binary is the
most ineffective, how can the XML datatype in
Yukon rely on a single binary itself? Is it because
it adapts the binary to a cited schema or because it
has its own vocabularies and datatype? 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?
<aside>Similar to a topic-based vector space model (see Becker,
Kuropa). A schema IS a TVSM. My head hurts.</aside>
Or is it the case that a binary for use in the dbms is always a
local (avoiding the term proprietary) binary?
IOW, there is no familial relationship among application
binaries and the dbms binaries, and furthermore, no good
reason to standardize the dbms binaries?
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?
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 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.
len
From: Michael Champion [mailto:michaelc.champion@gmail.com]
On 4/18/05, Michael Rys <mrys@microsoft.com> wrote:
> > However, the binary is reputed to create a faster parse. So
> > while there is no query performance effect, isn't the shredder faster,
> > that is, assuming XML on input? Wouldn't speeding up the
> > pipeline be useful given 2)?
>
> [Michael Rys] That depends on the binary format. For example, the
> fastest way for us to get XML data would have been if the
> closely-coupled client protocols (such as OLEDB, ADO.Net, ODBC, JDBC
> etc) would send us our internal binary XML. However, since we have to
> make sure that the binary XML is hardened against malicious attacks, we
> currently do not do this,
This illustrates why we at Microsoft are so skeptical of Binary XML
standardization. First, this potential for more efficient
communication between the API and the DBMS is an interesting use case
for "Binary XML", but there are many others with very different design
criteria. For example, an XQueryAPI -> XQuery-enabled DBMS use case
would require support for the XQuery type system to be useful, but
that would be overkill for other use cases such as efficient
transmission of SOAP messages, and possibly worse than XML text for
many wireless scenarios. Also, as Michael Rys mentions (and Elliotte
Harold has noted repeatedly), unless you are in a VERY tightly coupled
system you will have to parse/verify the data before dumping it in a
DBMS anyway. The performance gains from binary XML are non-trivial,
but not exactly mind boggling either. We really have to ask whether
the speedup is worth the cost of making XML interoperability
problematic once again, just when XML 1.0 / XSD 1.0 interop is
starting to become something that people can count on..
> > Since value handling depends on the value shape (the difference
> > in working with unstructured text vs delimited text (the case
> > for say long strings of vector values)), the relational model
> > isn't the issue: microparsing is, and again, it might be better
> > to be getting a binary back for some document types. The
> > increase in parser space could be worth it if one handles a
> > lot of documents of that type.
Right. There are all sorts of ways to significantly optimize XML
infoset interchange *if* you can constrain the structures,
vocabularies, datatypes, etc. beforehand. So, "Binary XML" approaches
can make a lot of sense ... but the problem is that once you relax all
these constraints and look for a general-purpose binary XML format,
all the stats I've seen show much less significant improvements. So,
my mantra is that Binary XML is a very interesting application-level
technology, but has little real potential for standardization at this
point.
> > and about experts that tell me Microsoft
> > is dumping XQuery for anything except SQL Server.
>
> [Michael Rys] If you refer to us not shipping XQuery on the mid-tier:
> This is currently the case, since we have not seen enough user-scenarios
> that satisfy the investment (besides the obvious scheduling issue). I am
> interested in seeing your scenarios though (feel free to send me and
> Mike Champion private mail on this, if you like).
I'd reiterate what Michael Rys said ... Note that we're not
necessarily "dumping" XQuery in .NET except for the "Whidbey" release
since the Recommendation didn't come out in time. But to be perfectly
honest, we are getting very little feedback (ahem, except from XQuery
stakeholders of one sort or another!) suggesting that the lack of a
client/mid-tier XQuery story will create problems for .NET customers.
FAR more people complained about not having an XSLT 2 story back when
the plan was to focus on XQuery. I literally have not heard directly
from a single end user with a client-side XQuery use case in my 4
months "owning" this problem at MS. Feel free to be the first :-)
|
