A very interesting exchange that came through my RSS feeds this morning - starting with Jon's piece about exposure of his server to ad-hoc XQuery and XPath queries.
I have some commentary relating to what is currently achievable re. XQuery in response to Don's blog post which is excerpted below:
Dare and David on XQuery
Dare just replied to David Orchard?s initial missive on remotingXQuery.
I don?t think either party is giving security sufficient weight.
How many web sites got hacked by SQL insertion attacks?
SQL insertion attacks were primary SQL Server based, and even in this case fronting SQL Server with ODBC Drivers that are equipped with security enhancements would have prevented this, but unfortunately FREE rules, and does so until the ultimate realization that there are "No Free Lunches".
In general, allowing user-defined programs (even functional programs like XQuery or SQL select statements) to be submitted to your service requires non-trivial support from the underlying runtime. Can I put an upper-bound on compute resources for a given query? Can I limit access to extension functions that my engine exposes, perhaps based on security priviledges? How about limiting visibility to portions of my underlying data?
Without solving the security problem first, this idea is a non-starter.
These security concerns aren't of the blanket kind, what I mean by this, is that one shouldn't take a single or given implementation scenario and then apply across the board to XQuery as a whole.
I know how to solve these for the .NET implementation of XPath 1.0. I don?t know how to solve these for J. Random XQuery implementation.
The point I am making above. Don has a solution for a given implamenation scenario, and so if this path was, or is, taken his concerns would be alleviated. Likewise, at OpenLink we have XQuery support, and our implementation doesn't suffer from the security concerns raised by Don.
Dare is correct that to date, there is no DML aspect to XQuery, however, that sound you hear is the sound of inevitability. There are proposals floating around the net and it?s just a matter of time before it happens.
Assuming one could secure such a beast, I?m more optimistic than Dare about the utility of exposing an XQuery head for straight queries (that is, no-DML).
Views are the data-centric version of encapsulation. The RDBMS world has shown that views give people insulation from database schema and for read-only access, they allow users to more flexible access to the store without getting a DBA to install yet another SPROC.
Thus, if XML data is exposed/published based on a SQL-XML basis, then it's pretty obvious that what is good for the SQL-VIEW is also good for the XQuery data source since it's derived from a VIEW, or is defined to behave like a SQL VIEW albeit within the context of XML.
This Blog is driven by an OpenLink Virtuoso Engine, and everything you read is coming out of a SQL Engine that transforms data to XML in a variety of ways (leveraging the fact that this DB Engine has an in-build XSLT processor amongs other things).
I can expose any portion of my blog to the public for XQuery or XPath queries, and control resource consumption and security via the underlying definition of the XML docs (i.e. scope of data covered, and the manner in which the data is materialized) that I choose to expose.
At the end of the day these issue are architecture and implementation specific.
I firmly believe that XQuery is critical inflection technology that ushers in the iminent replacement of today's Single-Protocol and Single-Function Web Servers, by Multi-Protocol and Multi-Function Web Servers.
All of today's HTTP urls are capable of becoming Query Execution entry points and more.
Recent Comments