Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML-enabled databases, XQuery APIs
 On 4/18/05, Bullard, Claude L (Len) <len.bullard@i...> 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
