[
Lists Home |
Date Index |
Thread Index
]
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 :-)
|
