 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / General DB Topics / DB Theory / March 2004Xquery might have some things right
My current interests related to software application development and the tools employed for such are aimed in two primary directions -- databases and distributed computing. XML plays in both of these categories. In discussions related to both topics, there is a lot of lashing out against XML as being a stupid approach to whatever it is it might be approaching. Marshall answered a recent post by indicating he is not a fan of XML, for example. I, too, have been know to state opinions about how it is not terribly important that persisted objects of any type (thought I'd toss in some OO terminology just to mess with a few of you) be human-readable in their persistent state. I don't have to be able to look directly at a CD and hear the music either. BUT, XML does have some things going for it, not the least of which is that it is our best bet yet for freeing ourselves of SQL -- a language with which I have a love-hate relationship, but which is ready for retirement, in my opinion. XQuery, the emerging standard where Microsoft seems to be putting their money, is something I have referred to as a "dog-ugly language" (although many dogs are cute) but it has some significant advances over SQL. I decided it was time to learn the language a bit more and foudn that it does employ a 2 valued logic (THANK GOODNESS!) as well as the obviously superior approach to nested data (multivalues) compared to the RDBMS's I have seen. Additionally, along with the data modeling related to a UI, one of the big areas ripe for database theorists to join web folks is data modeling as it relates to data searching. We think of search engines for semi-structured data (such as text documents on the web), but our applications have often been so restrictive in making users get their search criteria exactly right for database searches that we are going to need to adjust to more of a google approach at some point. We need to look at how a user will find a person, for example, when they recall that the word "green" is somewhere in that person's demographic data (was it their eyes or the street they live on or city they are from or one of their children or the company for which they work?) We tend to force users to know the attribute (at least the type) they are searching along with any partial or full values for that type. I suspect that XML will play a role in the area of database search engines. And ... XML is NOT based on relational data modeling theories (another thank goodness from me ;-). There is one huge deficiency (OK, more than one, but one I'll point out) with XQuery compared to SQL -- XQuery is a read-only language at this point, although update standards are being addressed. So, although XML is seen as an enemy "technology" to some database specialists and also to some distributed computing specialists, it is bringing with it some good news. [and, besides, for data exchange -- the best use of XML -- it was time to move on from comma-quote files anyway, right?] Are there XQuery fans on this list? --dawn In the last exciting episode, "Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote: > There is one huge deficiency (OK, more than one, but one I'll point > out) with XQuery compared to SQL -- XQuery is a read-only language > at this point, although update standards are being addressed. The deficiencies surely look like they are more enormous than any _conceivable_ merits. - If Microsoft is promoting it that can't conceivably be a good thing. That's actually a really useful property; "Microsoft Inside" is a terrific warning label. - It uses XML, the only thing that could have been worse than SGML, which was a text parsing system designed by people that didn't want to understand the theory of language parsers. - It depends on "success" in the shifting sands that are the foundation for XML "standards." Just look at the set of "standards" being published under the auspices of the W3C. Looks like a futile boondoggle to me...  Signatureoutput = ("cbbrowne" "@" "cbbrowne.com") http://www.ntlug.org/~cbbrowne/linuxdistributions.html Rules of the Evil Overlord #122. "The gun turrets on my fortress will not rotate enough so that they may direct fire inward or at each other. <http://www.eviloverlord.com/> > In the last exciting episode, "Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote: > > There is one huge deficiency (OK, more than one, but one I'll point [quoted text clipped - 3 lines] > The deficiencies surely look like they are more enormous than any > _conceivable_ merits. Yes, but it does have to walk before running -- it is an emerging standard still being brought to life. > - If Microsoft is promoting it that can't conceivably be a good thing. You would normally see me nodding in agreement, however, replacing ODBC (JDBC, OLE/DB) with a standard means of querying data that doesn't require SQL in the mix will require Microsoft's backing (money talks and all). > That's actually a really useful property; "Microsoft Inside" is a > terrific warning label. Major agreement from me. > - It uses XML, the only thing that could have been worse than SGML, > which was a text parsing system designed by people that didn't want > to understand the theory of language parsers. Again, complete agreement. > - It depends on "success" in the shifting sands that are the > foundation for XML "standards." Just look at the set of "standards" > being published under the auspices of the W3C. Definitely. And it was the foolish man who built his house upon the sand. I think the rule of thumb with software development tools & standards is to use something old, something new, something borrowed and something blue. My current choices in these categories are PICK, Jini, the JVM (borrowed-ish from Wirth's p-machine) and BlueJ (editor for writing Java code). > Looks like a futile boondoggle to me... You don't see a reasonable, though unbearably slow, progression from data exchange: 1. by putting data in "card columns" then virtual card columns distributed on mag tape 2. then ftp'ing or e-mailing comma-quote files 3. to now including the metadata for the data within the document itself It is a small step, but one that will make a significant contribution to software application integration, methinks. Cheers! --dawn Oops! "Dawn M. Wolthuis" <dwolt@tincat-group.com> was seen spray-painting on a wall: >> In the last exciting episode, "Dawn M. Wolthuis" <dwolt@tincat-group.com> > wrote: [quoted text clipped - 7 lines] > Yes, but it does have to walk before running -- it is an emerging > standard still being brought to life. It is clearly going in the wrong direction; you must start with a jewel of a good idea in order to have any hope that a standard will be as good as a "ball of mud." If you start with something less good than a jewel, then the result will be a "ball of something else." Standards processes represent a system of compromises that alway compromise, to some degree, the merits of what you started with. If you _start_ with something that is crud, then there is no way to go but even further down. >> - If Microsoft is promoting it that can't conceivably be a good thing. > > You would normally see me nodding in agreement, however, replacing > ODBC (JDBC, OLE/DB) with a standard means of querying data that > doesn't require SQL in the mix will require Microsoft's backing > (money talks and all). Hoping for Microsoft's "promotion" to be a good thing in any way, shape, or form is the wrong place to start. As with the 'standards process,' if you start with something that is any less than a shining jewel of clarity and beauty, by the time Microsoft gets through with it, it can't possibly be even as good as the SQL that you want to get away from. >> Looks like a futile boondoggle to me... > [quoted text clipped - 7 lines] > It is a small step, but one that will make a significant contribution to > software application integration, methinks. If you start with something that is not as good as SQL, and apply processes to it that are likely to degrade it, this does not look likely to provide a "significant contribution." SignatureIf this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me http://cbbrowne.com/info/emacs.html "I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)" -- Andrew Tanenbaum to Linus Torvalds > You don't see a reasonable, though unbearably slow, progression from data > exchange: [quoted text clipped - 6 lines] > software application integration, methinks. > Cheers! --dawn Leaving aside what is really gained by the "self-documentation" (if the file contains a <FOO> tag, and I don't know what a FOO corresponds to in my world...), it is a big jump from your step 3 to: 4. call your data exchange documents a DATABASE and use a procedural row-by-row file reader called XQuery instead of SQL. > > The deficiencies surely look like they are more enormous than any > > _conceivable_ merits. > > Yes, but it does have to walk before running -- it is an emerging standard > still being brought to life. Yes, but surely its foundations are either in place or not. It's far beyond "tweaking." > You would normally see me nodding in agreement, however, replacing ODBC > (JDBC, OLE/DB) with a standard means of querying data that doesn't require > SQL in the mix will require Microsoft's backing (money talks and all). I thought that's what OLE/DB was? I believe those technologies, and JDBC, don't require SQL at all - they just require processing to be done on a query. While JDBC is certainly geared toward SQL, and has SQL-specific extensions, the usual execute method would work on anything. You just have to supply the driver. In any event, XQuery simply pushes a lot more work on developers. Instead of saying what I want, I have to say how to get it, in gory dog-ugly detail. > > Looks like a futile boondoggle to me... > [quoted text clipped - 4 lines] > 2. then ftp'ing or e-mailing comma-quote files > 3. to now including the metadata for the data within the document itself The trouble is, metadata is already available. In JDBC, you can get lots of gory detail. In relational DBMSs with a standard catalog, much much more would be available - maybe Dataphor already provides it. But the data in an XML document is metadata in only a very limited way. It's barely useful for humans reading a doc, and of minimal value for a program. > It is a small step, but one that will make a significant contribution to > software application integration, methinks. > Cheers! --dawn It appears to for a few seconds if you squint, but the reality is that the Roman alphabet is insufficient to make me learn Romanian. - erk > - If Microsoft is promoting it that can't conceivably be a good thing. Except to MS stockholders. > That's actually a really useful property; "Microsoft Inside" is a > terrific warning label. Heh. > - It uses XML, the only thing that could have been worse than SGML, > which was a text parsing system designed by people that didn't want > to understand the theory of language parsers. Hey, don't blame them - information technology professionals have self-lobotomized en masse and followed the "text markup professionals" right to the gates of hell... > - It depends on "success" in the shifting sands that are the > foundation for XML "standards." Just look at the set of "standards" > being published under the auspices of the W3C. Well, we'll be able to cope with ever-changing "standards" once the "semantic web" is fully in place, y'know. :-) > Looks like a futile boondoggle to me... To paraphrase Fabian Pascal: this is one of those cases where one does not know whether to laugh or to cry. - erk > SGML, > which was a text parsing system designed by people that didn't want > to understand the theory of language parsers. Any references to this? Now you got me interested... SignatureLeandro Guimarães Faria Corcete Dutra Maringá, PR, BRASIL +55 (11) 5685 2219 http://br.geocities.com./lgcdutra/ +55 (44) 3028 7467 Soli Deo Gloria! +55 (44) 3028 8335 Quoth Leandro Dutra <ldutra@wlt.com.br>: >> SGML, >> which was a text parsing system designed by people that didn't want >> to understand the theory of language parsers. > > Any references to this? Now you got me interested... Hmmm. The "best" one I can see is thus... <http://naggum.no/erik/sgml/against.html> The oral history I have heard from various people that have been watching SGML since its beginnings have indicated this. The way they bodged in the notion of "document architectures" was a good example of the trouble with it. Actually trying to _use_ architectures for other than trivial things was pretty much beyond human reason. The breakage was particularly found when they tried defining "HyTime," a model for hypermedia documents that would have to include component documents. The problem the designers ran into was that while HyTime had to be an SGML application, they could not define a DTD for it. And that's essentially where it all fell down. They couldn't build HyTime the way they needed to. I expect that's what drove Naggum out of his research work on SGML... Signature"cbbrowne","@","cbbrowne.com" http://www.ntlug.org/~cbbrowne/internet.html Rules of the Evil Overlord #156. "If I have the hero and his party trapped, I will not wait until my Superweapon charges to finish them off if more conventional means are available." <http://www.eviloverlord.com/> > The oral history I have heard from various people that have been > watching SGML since its beginnings have indicated this. SGML was standardization of GML done at the cambridge science center circa 1970 by "G", "M", "L" (the choice of generalized markup language comes from the intials of the three people that work on it). GML processes added to the existing implementation of the CMS SCRIPT command (i.e. cambridge monitor system ... also done at the cambridge science center). misc. past posts about (s)gml history: http://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ? http://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general) http://www.garlic.com/~lynn/2002h.html#17 disk write caching (was: ibm icecube -- return of http://www.garlic.com/~lynn/2002o.html#4 Mainframe Spreadsheets - 1980's History http://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and literature http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques? At least "L" went on to work on RDBMS BLOBs ... towards the end of the System/R (possibly transition to R-star?) .. there were half dozen or so of use that transferred out of cambridge to san jose about the same time. some specifics about the gml history http://www.sgmlsource.com/history/ http://www.sgmlsource.com/history/roots.htm http://www.sgmlsource.com/history/jasis.htm http://www.sgmlsource.com/history/G320-2094/G320-2094.htm other science center postings: http://www.garlic.com/~lynn/subtopic.html#545tech SignatureAnne & Lynn Wheeler - http://www.garlic.com/~lynn/ > My current interests related to software application development and the > tools employed for such are aimed in two primary directions -- databases and > distributed computing. XML handles data? I suppose someone who can have two "primary" directions probably wouldn't be too troubled by the difference between data and text. Roy Hann PS: Am I the first to point out that there is no 'w' in dolt? > > My current interests related to software application development and the > > tools employed for such are aimed in two primary directions -- databases [quoted text clipped - 3 lines] > XML handles data? I suppose someone who can have two "primary" directions > probably wouldn't be too troubled by the difference between data and text. I write some things that I figure will only make me smile, so I'm pleased to see you picked up on that, Roy. [My use of the word "primary" for more than one item stems from primary key discussions] And by the way, text with associated metadata is a subset of all possible data by my definitions. What is it lacking to be considered data in your definition? > Roy Hann > > PS: Am I the first to point out that there is no 'w' in dolt? OK, that was clever enough -- just don't make a habit of it. > XML handles data? I suppose someone who can have two "primary" directions > probably wouldn't be too troubled by the difference between data and text. > > PS: Am I the first to point out that there is no 'w' in dolt? It should be fairly easy to refute any given XML-based argument without resorting to name calling. Marshall > > XML handles data? I suppose someone who can have two "primary" directions > > probably wouldn't be too troubled by the difference between data and text. [quoted text clipped - 3 lines] > It should be fairly easy to refute any given XML-based argument > without resorting to name calling. Couldn't agree more. Apparently I missed the humor in the response, but didn't miss the rudeness. > > "Roy Hann" <rhann@globalnet.co.uk> wrote in message > news:c249vv$okq$1@sparta.btinternet.com... [quoted text clipped - 11 lines] > Couldn't agree more. Apparently I missed the humor in the response, but > didn't miss the rudeness. Me too! What is it about this group that makes people feel the need to smear, degrade and belittle anybody and everybody who "dares" to post here? > Are there XQuery fans on this list? --dawn Not many, but it does not surprise me that you are one of them. Look: a procedural way of querying a hierarchic database. What a great leap forward! > > Are there XQuery fans on this list? --dawn > > Not many, but it does not surprise me that you are one of them. You didn't read very well. I have more often critcized XQuery than applauded it and it is only in the last week that I decided to learn it better so that any criticisms had more knowledge at the base. It is then that I found a few gems and thought I'd pass them along. > Look: > a procedural way of querying a hierarchic database. What a great leap > forward! Ah, blinded by glasses you have been wearing for, perhaps, too long? You should rather think of it as a means of navigating di-graphs of data. When both the data model and the data operators are represented as functions (which, by definition are relations), there are some gains we can make. Think of all of the work to be done in terms of function(input)=output If we represent all input and output as functions (such as ObjectFunction(referenceID) = objectdata), then there is only one type of data (for storage purposes, for example) -- FUNCTIONS! That's it -- you apply one function to another until you get the function to store or output in some other way. smiles. --dawn > > "Dawn M. Wolthuis" <dwolt@tincat-group.com> wrote in message > news:<c23ic9$usb$1@news.netins.net>... [quoted text clipped - 6 lines] > better so that any criticisms had more knowledge at the base. It is then > that I found a few gems and thought I'd pass them along. You are correct: I have missed the posts where you criticise XQuery, sorry. > > Look: > > a procedural way of querying a hierarchic database. What a great leap > > forward! > > Ah, blinded by glasses you have been wearing for, perhaps, too long? You > should rather think of it as a means of navigating di-graphs of data. And that would be better because...? I don't want to "navigate" through the data, since I know a better way: define the sets of data I want, and leave the DBMS to "navigate" however it decides is optimal. Why should *I* have to do all the work? > When both the data model and the data operators are represented as functions > (which, by definition are relations), there are some gains we can make. [quoted text clipped - 7 lines] > apply one function to another until you get the function to store or output > in some other way. Sounds like LISP (which I quite liked in a quirky sort of way at one time). However, relational databases only have one type of data too - relations! And SQL databases (not really the same thing, as I'm sure you are only too aware by now) have only tables - if you ignore some of the egregious OO "extensions". > > Look: > > a procedural way of querying a hierarchic database. What a great leap > > forward! > > Ah, blinded by glasses you have been wearing for, perhaps, too long? You > should rather think of it as a means of navigating di-graphs of data. Why navigate? That implies knowing too much about the graph's structure. Relations are different - you say what you want. > When both the data model and the data operators are represented as functions > (which, by definition are relations), there are some gains we can make. [quoted text clipped - 7 lines] > apply one function to another until you get the function to store or output > in some other way. So why do you program in Java and use XML? Lisp and S-expressions are sufficient. - erk > My current interests related to software application development and the > tools employed for such are aimed in two primary directions -- databases and > distributed computing. Remember Fowler's First Law of Distributed Object Design: Don't distribute your objects! His quote: "Sell your favorite grandma first if you possibly can." I truly worry that we distribute too much, too soon, when a much simpler approach would have worked. > XML plays in both of these categories. Hmmm. XML plays in many categories, mostly because people keep dragging it out to play. It's like the rich kid everybody wants to play with because it has an aura and they have the vague feeling they might get something out of it. > In discussions related to both topics, there is a lot of lashing out against > XML as being a stupid approach to whatever it is it might be approaching. Defining that is really the problem. Generally if something approaches everything, it truly approaches nothing. > Marshall answered a recent post by indicating he is not a fan of XML, for > example. I, too, have been know to state opinions about how it is not > terribly important that persisted objects of any type (thought I'd toss in > some OO terminology just to mess with a few of you) be human-readable in > their persistent state. I don't have to be able to look directly at a CD > and hear the music either. Good analogy for some uses. > BUT, XML does have some things going for it, not the least of which is that > it is our best bet yet for freeing ourselves of SQL -- a language with which > I have a love-hate relationship, but which is ready for retirement, in my > opinion. XML is a bet for freeing ourselves of SQL? XML isn't a language, isn't really declarative (well... never mind), and has little overlap that I can see. I'd be interested to know what XML does better than SQL, and in what area. > XQuery, the emerging standard where Microsoft seems to be putting > their money, is something I have referred to as a "dog-ugly language" > (although many dogs are cute) but it has some significant advances over SQL. Such as? > I decided it was time to learn the language a bit more and foudn that it > does employ a 2 valued logic (THANK GOODNESS!) What do you mean by this? How is XQuery's approach different? > as well as the obviously > superior approach to nested data (multivalues) compared to the RDBMS's I > have seen. You can do this in SQL too - it's not a good idea, but we've already beaten that dead straw horse up a tree (to badly combine three metaphors). Again, how is XQuery better? Every example query I've seen looks like the output of an horrendous acid trip. > Additionally, along with the data modeling related to a UI, one of the big > areas ripe for database theorists to join web folks is data modeling as it [quoted text clipped - 3 lines] > for database searches that we are going to need to adjust to more of a > google approach at some point. I don't think it's the same thing. Doing a Google search means you don't know exactly what you're looking for, and typically you're a little flexible in what you get (e.g. any of a hundred pages might have what you need). That's a different story than in business data, where presumably the users are professionals and understand something about what they're doing. If they don't, that's a different sort of problem. Not that tools like Lucerne and such aren't useful, but we're not talking about the Google problem domain in most apps. > We need to look at how a user will find a > person, for example, when they recall that the word "green" is somewhere in > that person's demographic data (was it their eyes or the street they live on > or city they are from or one of their children or the company for which they > work?) We tend to force users to know the attribute (at least the type) > they are searching along with any partial or full values for that type. It's not exactly demanding to force the user to know they're searching for eye color, or street, or whatever... those are domains. Unless you mean "I'm looking for that green guy - dunno if it was green hair, green eyes, Mr. Green, or Green Avenue..." I don't think that brand of search is really that typical in business applications. > I suspect that XML will play a role in the area of database search engines. XML is a data format. XPath/XQuery expressions might be useful to interrogate data of an XML type, but beyond that using XML just cripples your query (reasoning) capabilities. > And ... XML is NOT based on relational data modeling theories (another thank > goodness from me ;-). Why? Just the MV "thang"? > There is one huge deficiency (OK, more than one, but one I'll point out) > with XQuery compared to SQL -- XQuery is a read-only language at this point, > although update standards are being addressed. I think its biggest problem is the hierarchical, procedural nature of its queries. Say what you want about SQL, but at least you don't have to tell it EXACTLY what order you want it to search in! XQuery is a huge burden for developers, and gives precisely zero room for optimization. > So, although XML is seen as an enemy "technology" to some database > specialists and also to some distributed computing specialists, it is > bringing with it some good news. [and, besides, for data exchange -- the > best use of XML -- it was time to move on from comma-quote files anyway, > right?] Yes, data exchange is a decent use of XML. Text markup is what it was invented for, however, and it does that well - but keep in mind that marked-up text is a type, and that operations over that type (e.g. returning more marked-up text based on an XPath or XQuery "expression") are a reasonable use of a type (domain), even in a relational database! It's when you start envisioning all of your data as hierarchies that you run into massive, massive problems which will only compound as they worm their way to the heart of the enterprise (god help us all). > Are there XQuery fans on this list? --dawn Sorry - you've just referenced the empty set. :-) - erk > Yes, data exchange is a decent use of XML. I doubt it. You have System A which want to get some information from System B. How do you do that? Query it (what a surprise). The underlying transport beneath SQL connection doesn't really matter. > > Yes, data exchange is a decent use of XML. > > I doubt it. You have System A which want to get some information from System > B. How do you do that? Query it (what a surprise). The underlying transport > beneath SQL connection doesn't really matter. No, you use simple publish and subscribe mechanisms. In which case exchaning data with XML works quite well. --Corey > > > Yes, data exchange is a decent use of XML. > > > > I doubt it. You have System A which want to get some information from System > > B. How do you do that? Query it (what a surprise). The underlying transport > > beneath SQL connection doesn't really matter. Well, I was trying to be kind. Remember that "decent use of XML" is simply a comparison to "horrendous uses of XML," and wasn't comparing XML with other technologies and formats. > No, you use simple publish and subscribe mechanisms. In which case exchaning > data with XML works quite well. But it's just a format, whatever mechanism you use to exchange it. Publish and subscribe can be useful, but WHAT is published can be anything. XML is a wordy format, and doesn't get the parties involved out of the business of having to know the semantics of the data elements. > > "Mikito Harakiri" <mikharakiri@iahu.com> wrote in message > news:KkN1c.43$ia.170@news.oracle.com... [quoted text clipped - 18 lines] > wordy format, and doesn't get the parties involved out of the business of > having to know the semantics of the data elements. Sure, that's why you need an AAIS (application to application interface specification), otherwise how will you define the contract between one system and the other? XML does have "some" advantanges. Here's a short list: - It's human readable. Developers can visually check on communications between systems simply by taping into the communications channel. Great for debugging too. - Senders and receivers don't have to be in perfect sync. That is, information can be added at the transmitter that the receiver can simply ignore. This works especially well in a publish subscribe scenario where the subscribers use the published output in different ways. Sure it's wordy and shouldn't over extended to do things that it was never intended to do. But that doesn't mean that it's not useful for certain classes of computing problems. Regards --Corey > Sure, that's why you need an AAIS (application to application interface specification), > otherwise how will you define the contract between one system and the other? Definitely - my point was that XML doesn't absolve you of that responsibility. > XML does have "some" advantanges. Here's a short list: > > - It's human readable. Developers can visually check on communications between systems > simply by taping into the communications channel. Great for debugging too. Recently I've been dealing with comma-delimited data being sent from one system to another. I find it no less readable than some of the XML docs I cope with at work. In some simple, short cases, you might be right, but for a system of any sophistication, I find the format tedious. I still need a tool (like XMLSpy) to cope with the inevitable removal of line breaks from XML streams - I can't read those things in one big block. And if I have to open a tool, well, many tools will work. XML is fine for writing short docs in a text editor - after that, things get hairy. > - Senders and receivers don't have to be in perfect sync. That is, information can be added > at the transmitter that the receiver can simply ignore. This works especially well in a publish > subscribe scenario where the subscribers use the published output in different ways. That's true of my comma-delimited data too. I have a line with field names. It's trivial to suck the data and field names into Perl and get a nice hash of field to value, and trivial to only grab the ones you care about. All with less code than typical XML-related code (even with a parser!). I'm not advocating comma-delimited, by the way - just mentioning that I've yet to see many of the stated benefits of XML materialize for me. - erk > > "Eric Kaun" <ekaun@yahoo.com> wrote in message > news:dn%1c.55833$1O4.38437@newssvr33.news.prodigy.com... [quoted text clipped - 21 lines] > open a tool, well, many tools will work. XML is fine for writing short docs > in a text editor - after that, things get hairy. Ok, but there's no reason why the "XML" has to be hairy. comma-delimited data has it's advantages and disadvantages too. Inparticular, how do you send a variable length list of data for any particular variable in a CSV document? There are advantages and disadvantages to both approaches. :-) I just find XML to be rather convenient sometimes. > > - Senders and receivers don't have to be in perfect sync. That is, > information can be added [quoted text clipped - 7 lines] > of field to value, and trivial to only grab the ones you care about. All > with less code than typical XML-related code (even with a parser!). Ah, but you've kinda stretched the meaning of CSV in that you have included both a name AND a value pair separated by comma delimiters. You also still have the same problem as mentioned above. You can't define variable length lists of values for any particular name or attribute. When I think of CSV, I think of pure values separated by commas. In which case the client and server must be in perfect sync. > I'm not advocating comma-delimited, by the way - just mentioning that I've > yet to see many of the stated benefits of XML materialize for me. I think both have their place in solved certain classes of computing problems. It's always good to have more tools in your tool box than not. ;-) Regards, --Corey > - erk > > "Eric Kaun" <ekaun@yahoo.com> wrote in message > news:dn%1c.55833$1O4.38437@newssvr33.news.prodigy.com... <snip> I'm not advocating comma-delimited, by the way - just mentioning that I've > yet to see many of the stated benefits of XML materialize for me. I agree, with the exception of making it easier to move nested data from one place to another without 1NF-ing if first, XML is just one tiny step up from comma-quote. And comma-quote was just one tiny step up from putting data in various "card columns" (on real or virtual cards). While there are definitely benefits today for those of us who don't do that 1NF thing ;-) the benefits to those with RDBMS's will not be there until the XML documents are able to be used as a standard input and output format that is wrapped in a standard wrapper (e.g. SOAP, somewhat analogous to ODBC) for communication between a client and a service. The standard could have been based on comma-quote or even card columns for that matter (although there is no metadata with those), but it wasn't. I'll agree that XML is a teeny-tiny step for data exchange purposes, but the services design pattern that just might emerge as a standard along with XML documents does hold some promise, I think. Cheers! --dawn > I'll agree that XML is a teeny-tiny step for data exchange purposes, but the > services design pattern that just might emerge as a standard along with XML > documents does hold some promise, I think. Cheers! --dawn I'd still like to hear a good definition for "services design pattern". I'm not being facetious... I'd just like to be clear on what differentiates services from other forms of remote call we've had in the past. > > I'll agree that XML is a teeny-tiny step for data exchange purposes, but > the [quoted text clipped - 5 lines] > not being facetious... I'd just like to be clear on what differentiates > services from other forms of remote call we've had in the past. Yes, yes -- I put one in another thread -- I couldn't put my finger on where that question was. Here are definitions that R. Dale Asberry sent from the jini-users list. "A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services." and according to the W3C: "a service is a software agent that performs some well-defined operation (i.e., "provides a service") and can be invoked outside of the context of a larger application." I have a few I penned as well, but I especially liked being clear that (from a mathematical perspective) it is a function. --dawn > I'd still like to hear a good definition for "services design pattern". I'm > not being facetious... I'd just like to be clear on what differentiates > services from other forms of remote call we've had in the past. I don't see any reason to think it's anything other than client-server computing under a new name. You get RPC but with XML as the transport. That's one beef I have with XML and its ilk; they like to come up with new names for old things and act as if they've invented something miraculous. Marshall > > I'd still like to hear a good definition for "services design pattern". I'm > > not being facetious... I'd just like to be clear on what differentiates [quoted text clipped - 7 lines] > with new names for old things and act as if they've invented something > miraculous. Exactly right. I used to think Fabian Pascal was a curmudgeon, correct but a little too Chicken Little. After reading the trade rags and W3C specs with a slightly more intellectually critical eye, however, one quickly sees the regurgitative process at work. And regurgitating mostly garbage too! - Eric "Call me Curmudgeon" Kaun > > I'd still like to hear a good definition for "services design pattern". I'm > > not being facetious... I'd just like to be clear on what differentiates [quoted text clipped - 7 lines] > with new names for old things and act as if they've invented something > miraculous. It's not that bad. Of course you are right. A webservice is just RPC with underlying XML communication. But then this allows breaking platform barriers. Or how do you implement RPC between a Java program and Cobol on mainframes on the other side? Either you use a middleware product, or you use XML. And guess what: Today middleware also supports XML communication. Hiran > Or how do you implement RPC between a Java program and Cobol on > mainframes on the other side? Either you use a middleware product, or you > use XML. And guess what: Today middleware also supports XML communication. Wonderful definition. XML is a buzzware that allows to connect to legacy COBOL systems. > > Or how do you implement RPC between a Java program and Cobol on > > mainframes on the other side? Either you use a middleware product, or you > > use XML. And guess what: Today middleware also supports XML communication. > > Wonderful definition. XML is a buzzware that allows to connect to legacy > COBOL systems. You misinterprete my expression. I said it can be used for that, so it was an example - not a definition. What's going on here? Hiran > > > Or how do you implement RPC between a Java program and Cobol on > > > mainframes on the other side? Either you use a middleware product, or [quoted text clipped - 8 lines] > an example - not a definition. > What's going on here? How can it be used? Legacy COBOL systems have no idea about RPC, Java RMI, or SOAP. You have to write adapter on the COBOL communication side anyway. And Protocol can be anything. > > You misinterprete my expression. I said it can be used for that, so it was > > an example - not a definition. [quoted text clipped - 3 lines] > or SOAP. You have to write adapter on the COBOL communication side anyway. > And Protocol can be anything. Replace the word Cobol with Natural, and the XML interface is real now. So what keeps you from believing that this is a possible way to go? The perhaps missing implementation? If you need it, I can build one. Hiran in message news:c358aa$4n0$1@wsc10.lrz-muenchen.de... > > "Eric Kaun" <ekaun@yahoo.com> wrote in message > news:bi22c.55867$%b5.36952@newssvr33.news.prodigy.com... [quoted text clipped - 3 lines] > > > not being facetious... I'd just like to be clear on what differentiates > > > services from other forms of remote call we've had in the past. The differentiation will be in *what* is fetched. > > I don't see any reason to think it's anything other than client-server > > computing under a new name. You get RPC but with XML as [quoted text clipped - 9 lines] > mainframes on the other side? Either you use a middleware product, or you > use XML. And guess what: Today middleware also supports XML communication. There is another option ... I have called it RDBMS portal software as its whole function is simply to send RPC calls to the RDBMS and to (generically) handle the output data sets returned from the RDBMS executing such calls. You then write all application level code in the form of (R)DBMS stored procedures and allow the portal software to be the user interface. The end result is .... * no client application environment (except the portal software) * no application development environment external to the database * the leanest and meanest performance benchmarks possible * simplicity - for we are dealing only with the RDBMS technology. Middleware is a bridge between an (often existent) application and an (R)DBMS. The contruction costs of (getting and using) middleware are often far less than rebuilding the application correctly from the ground up. SignaturePete Brown Winluck P/L IT Managers & Engineers Falls Creek Australia www.mountainman.com.au/software > I have called it RDBMS portal software as its whole function is simply > to send RPC calls to the RDBMS and to (generically) handle the output > data sets returned from the RDBMS executing such calls. This is an excellent idea. And I have seen middleware that uses 'persistent message queues' that exactly store the messsages in a database. But back to the thread: I belive XML does not just present new solutions to old ideas. It solves some problems, which we would have to deal with otherwise. I do not claim that they are not solveable - if they were, XML also could not do the trick. But as it does, we can focus our thoughts to higher levels of abstraction, and wide-spread interoperability comes into reach. It's a bit like the first graphical user interfaces. In the beginning noone really needed them, today there are user interfaces noone would ever dream of using on a TTY.... Hiran > But as it does, we can focus our thoughts to > higher levels of abstraction, and wide-spread interoperability comes into > reach. CORBA deja vu? > > But as it does, we can focus our thoughts to > > higher levels of abstraction, and wide-spread interoperability comes into > > reach. > > CORBA deja vu? Is CORBA that flexible? How come it is not that widely used then? How come there are so many of such systems? And still, it is not the only use for XML. Hiran > > > But as it does, we can focus our thoughts to > > > higher levels of abstraction, and wide-spread interoperability comes [quoted text clipped - 4 lines] > > Is CORBA that flexible? How come it is not that widely used then? No, XML is doomed to repeat CORBA failure. > And still, it is not the only use for XML. I don't see any utility for XML beyond cutting and pasting quotes into usenet messages like this: <quote> ... </quote> Quoth "Mikito Harakiri" <mikharakiri@iahu.com>: >> > > But as it does, we can focus our thoughts to >> > > higher levels of abstraction, and wide-spread interoperability comes [quoted text clipped - 14 lines] > ... > </quote> Since there is: a) No RFC for that, and b) No clients that support that, and c) Great trouble in making up a suitable user interface to manage quoting properly anyways, it's no good anyways. Signature(reverse (concatenate 'string "gro.gultn" "@" "enworbbc")) http://cbbrowne.com/info/lisp.html Nobody can fix the economy. Nobody can be trusted with their finger on the button. Nobody's perfect. VOTE FOR NOBODY. > > > > But as it does, we can focus our thoughts to > > > > higher levels of abstraction, and wide-spread interoperability comes [quoted text clipped - 14 lines] > ... > </quote> Technically speaking, isn't the above only sgml and not necessarily xml per se? > > I don't see any utility for XML beyond cutting and pasting quotes into > > usenet messages like this: [quoted text clipped - 4 lines] > Technically speaking, isn't the above only sgml and not necessarily xml per > se? I always heared that XML is a subset of SGML. Regards Alfredo XML has two parents: SGML and the standard modeling language X. > > > I don't see any utility for XML beyond cutting and pasting quotes into > > > usenet messages like this: [quoted text clipped - 9 lines] > Regards > Alfredo > XML eXclusively Made for Laymen > > XML > > eXclusively Made for Laymen Unfortunately, I think it's "eXclusively Made >by< Laymen". Too bad information "professionals" have paraded along behind like rats following the Pied Piper of Hamelin... > > I have called it RDBMS portal software as its whole function is simply > > to send RPC calls to the RDBMS and to (generically) handle the output [quoted text clipped - 13 lines] > really needed them, today there are user interfaces noone would ever dream > of using on a TTY.... I see no solution to anything in XML that was not already solved years ago. > I agree, with the exception of making it easier to move nested data from one > place to another without 1NF-ing if first, XML is just one tiny step up from > comma-quote. And comma-quote was just one tiny step up from putting data in > various "card columns" (on real or virtual cards). What is the big deal about moving data from one place to another? create dblink to RemoteSystemA insert into LocalTableA select * from A@RemoteSystemA Unlike my simplistic example, in the real world you have all the power of Relational Algebra & Calculus mix in SQL in order to make required interim data transformations. (Yes, data transformations are relational views, not some goofy stylesheets). Imagine RemoteSystemA owner provided you with EDI, XML or others ShmackML instead of remote database connection. Suppose all you need to know is how many purchase orders did the system processed last month. Does it mean you have to import *all* the orders to your system first? > Imagine RemoteSystemA owner provided you with EDI, XML or others ShmackML > instead of remote database connection. Suppose all you need to know is how > many purchase orders did the system processed last month. Does it mean you > have to import *all* the orders to your system first? Of course not. The remote system is most likely Object-Oriented, so you merely navigate, a/k/a chase pointers, to the orders collections, iterate through each and every order, and maintain a counter. That's N+K network round trips for N orders, where K is finite but unbounded. -- Joe Foster <mailto:jlfoster%40znet.com> Wanna buy a Bridge? <http://xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha! > > Imagine RemoteSystemA owner provided you with EDI, XML or others ShmackML > > instead of remote database connection. Suppose all you need to know is how [quoted text clipped - 5 lines] > iterate through each and every order, and maintain a counter. That's > N+K network round trips for N orders, where K is finite but unbounded. How convenient. :-\ > > "Mikito Harakiri" <mikharakiri@iahu.com> wrote in message > <news:3z32c.18$zW4.150@news.oracle.com>... [quoted text clipped - 13 lines] > > How convenient. :-\ What is the theory on which we base "our" disdain for navigation? Is the only rationale performance? In other words, if there were a data model where the implementation was zippy quick and navigation was a strategy for getting there, then is there something else upsetting about the navigation approach? Thanks. --dawn > > > "Mikito Harakiri" <mikharakiri@iahu.com> wrote in message > <news:3z32c.18$zW4.150@news.oracle.com>... [quoted text clipped - 19 lines] > strategy for getting there, then is there something else upsetting > about the navigation approach? It isn't a theoretical disdain. It is based on the fact that with navigation you have to specify how to get the result, not just what result you want. One of the strange things about many programmers is that they don't trust computers, and always prefer to do all the work themselves. > > > > "Mikito Harakiri" <mikharakiri@iahu.com> wrote in message > > <news:3z32c.18$zW4.150@news.oracle.com>... [quoted text clipped - 16 lines] > > What is the theory on which we base "our" disdain for navigation? Is > > the only rationale performance? No, it's just another manifestation of the (admittedly vague) what/how distinction. We should, at this point in the history of computing, be specifying WHAT we want, not how to get it. It's as if the (necessary) operational thinking that dominated the design of processors now dominates everything we do, rather than allowing us to return to "pure" logic, where we can actually achieve conceptual traction. > > In other words, if there were a data > > model where the implementation was zippy quick and navigation was a [quoted text clipped - 6 lines] > that they don't trust computers, and always prefer to do all the work > themselves. A huge problem. I'm less and less in favor of "flexibility" in language design for commercial / industrial systems, since this is so often abused to no one's benefit. Specifying an access path, as opposed to simple criteria for selection, makes a world of difference. - Eric > > dwolt@iserv.net (Dawn M. Wolthuis) wrote in message > news:<6db906b2.0403221645.1141ecf6@posting.google.com>... > > > "Eric Kaun" <ekaun@yahoo.com> wrote in message > news:<9JC7c.62219$lV6.25494@newssvr33.news.prodigy.com>... > > > > > "Mikito Harakiri" <mikharakiri@iahu.com> wrote in message > <news:3z32c.18$zW4.150@news.oracle.com>... <snip> > > > > > What is the theory on which we base "our" disdain for navigation? Is > > > the only rationale performance? [quoted text clipped - 5 lines] > everything we do, rather than allowing us to return to "pure" logic, where > we can actually achieve conceptual traction. What we do might be described, in theory, not as a "how to" as a graph-theory navigation of a di-graph, just as it might be described as a set-theory operation, right? Either way, it is the application of a function/operation. Neither the end-user nor the programmer needs to do this navigation -- the vocabularly made visible in the metadata could include virtual "fields" that are derived via navigation -- but only the specification/definiton of that vocabularly needs to have the "how" spec. Do you agree there is nothing purer or truer about a set-theorectical operation than a graph-theory navigation? thanks. --dawn > > > In other words, if there were a data > > > model where the implementation was zippy quick and navigation was a [quoted text clipped - 13 lines] > > - Eric > > > dwolt@iserv.net (Dawn M. Wolthuis) wrote in message > > news:<6db906b2.0403221645.1141ecf6@posting.google.com>... [quoted text clipped - 18 lines] > as a set-theory operation, right? Either way, it is the application > of a function/operation. It could be, but you can also fall back to the Turing Machine argument and the fact that it's all just bits anyway, so why not use them directly? Graph theory is very complicated, and while it's certainly no more or less "correct" than set theory, I'd wager that the latter is more useful: tractable, automatable, and amenable to reason. Besides that, set theory (and relations specifically) allow better abstraction for data - specifically, the node structure no longer has an effect on "finding" something, and the "nodes" can be associated closely with predicates in the problem domain. I think there are probably many more, but that's a start... > Neither the end-user nor the programmer > needs to do this navigation -- the vocabularly made visible in the > metadata could include virtual "fields" that are derived via > navigation -- but only the specification/definiton of that vocabularly > needs to have the "how" spec. So with these virtual fields, you have to define not only the graph structures, but also the "meaningful" superimposition of a vocabulary on top of the graph structure, then finally the application logic on top of that vocabulary. Then you have to change the implementation of the vocabulary whenever the graph structure changes. An RDBMS, in effect, uses whatever graphs or other data structures it wants (see Transrelational, for example), raising the level of abstraction for developers in a way that doesn't lose anything. > Do you agree there is nothing purer or truer about a set-theorectical > operation than a graph-theory navigation? thanks. --dawn I agree. It's just more complex and fragile, and less useful. - erk "Eric Kaun" <ekaun@yahoo.com> wrote in message news:3Bh8c.28405> Graph > theory is very complicated, and while it's certainly no more or less > "correct" than set theory, I'd wager that the latter is more useful: > tractable, automatable, and amenable to reason. This reference to graph theory by people who don't understand any theory is a bluff. They what to substantiate their primitive pointer chasing method, and naively think that just throwing "graph theory" to the opponent face is strong enough argument. > "Eric Kaun" <ekaun@yahoo.com> wrote in message news:3Bh8c.28405> Graph > > theory is very complicated, and while it's certainly no more or less [quoted text clipped - 5 lines] > and naively think that just throwing "graph theory" to the opponent face is > strong enough argument. Could be, I don't know. What I do know is that my friends with stronger mathematical knowledge than me all cringe at generalized graph theory, while sets, relations, even rings and other topological concepts don't give them the same heebie-jeebies (that's a technical term, you know). Less dancing around NP-completeness and such... > Could be, I don't know. What I do know is that my friends with stronger > mathematical knowledge than me all cringe at generalized graph theory, while > sets, relations, even rings and other topological concepts don't give them > the same heebie-jeebies (that's a technical term, you know). Less dancing > around NP-completeness and such... I was referring to those "practitioners" like Dawn, who could hardly explain what graph theory is in the first place. As if their goofy usage of field dilimiters (or "modern" XML tags) somehow qualifies them as Graph Theory experts. > Sure, that's why you need an AAIS (application to application interface specification), > otherwise how will you define the contract between one system and the other? [quoted text clipped - 10 lines] > Sure it's wordy and shouldn't over extended to do things that it was never intended to do. > But that doesn't mean that it's not useful for certain classes of computing problems. Corey, may I ask you if you ever write a query in SQL? > > Sure, that's why you need an AAIS (application to application > interface specification), [quoted text clipped - 21 lines] > > Corey, may I ask you if you ever write a query in SQL? Yes, of course, but what does that have to do with using XML as a message protocol for publish and subscribe systems? > Yes, of course, but what does that have to do with using XML as a message > protocol for publish and subscribe systems? I don't see any XML relevance in the context of publish and subscribe systems. A client registers its interest in a certain event that may happen on a server. That is formally a rule: if a certain predicate becomes valid, then sever have to do some action (e.g. notify a client). That is the area of active database systems. Note that client notification is one of the possible actions (e.g. I want to sell the stock right away, I don't want to be merely notified that the stock price became attractive). There are multiple ways to implement notification too, for example, client can register remote callback, etc. Anyay, no matter what notification implementation is, the content of the message is too small to warrant making it XML. Once again, if the client needs more info, it can always query the server and this is far superior to any other alternative you may suggest. > implementation is, the content of the message is too small to warrant making > it XML. Once again, if the client needs more info, it can always query the > server and this is far superior to any other alternative you may suggest. The assumption that it's advantageous to keep notification small clearly doesn't apply to spam industry. > > Yes, of course, but what does that have to do with using XML as a > message [quoted text clipped - 14 lines] > it XML. Once again, if the client needs more info, it can always query the > server and this is far superior to any other alternative you may suggest. I can tell you haven't done this type of thing very often. What if we're talking about an entire network of "clients" that need to be notified. Would you send them some sort of notification and then allow every one of them to then perform a remote query on your servers local database? Doesn't sound like a very scalable solution to me? I think the slight amount of overhead introduced by using a wordy protocol like XML, when combined with a UDP broadcast, is far superior to the "pull" type system that you are suggesting. Regards, --Corey > I can tell you haven't done this type of thing very often. I haven't. It seems like everybody else is busy solving business integration problem, and they think they know better than Relational camp. How naive! > > I can tell you haven't done this type of thing very often. > > I haven't. It seems like everybody else is busy solving business integration > problem, and they think they know better than Relational camp. How naive! It also appears that the relational camp seems to think that they know more about systems integration then the people that have been doing it for years. How arrogant! > What if we're talking > about an entire network of "clients" that need to be notified. Would you send [quoted text clipped - 3 lines] > protocol like XML, when combined with a UDP broadcast, is far superior to > the "pull" type system that you are suggesting. Sorry, but no, there is no logical redundancy in my approach. Every client queries only the info they want to know. It is extremely rare when client wants the whole database. Usually, client query filters most of the data out according to some criteria. The other common case is aggregated report, where the output is small as well. In both cases extra information is quickly discarded on server and would never cross the network boundary. Whereas in your broadcasting proposal you flood the network with spam that clients rarely care about. > > What if we're talking > > about an entire network of "clients" that need to be notified. Would [quoted text clipped - 17 lines] > Whereas in your broadcasting proposal you flood the network with spam that > clients rarely care about. Sorry, you're wrong again. I described a publish and subscribe mechanism that broadcasts information only to those clients that have "subscribed" to that particular publication. In your solution, every client interested in a particular piece of information would have to query the server, essentially at the same time, to retrieve it. Unless you can think of some way of throttling your clients, I don't see how your solution would ever scale. Allowing clients to directly query the server via SQL makes your design too fragile for real world application. Server side schema or application changes will immediately break every client in your system. Your solution requires that clients have intimate knowledge of the servers table structures in order to properly formulate a "query" that would allow the client to pull the information that they're interested in. Interfaces between systems must form an abstraction layer between the server and the client in order to insulate one from the other and to allow for application flexibility. Not to mention, I don't know of too many application owners that are going to allow untrusted clients to have direct database access to their systems. Even if the access is in a read-only mode, there may be information stored on the server that is considered sensitive and cannot be shared with other systems. For instance let's say your bank account numbers or social security number was stored along with your stock information. Would you want external clients to be able to randomly query for such information? An AAIS is the only real world solution, and the AAIS has to be agreed upon by both parties. The message protocol used between the server and client needs to be robust enough to allow the server to be able to service multiple clients with the same message protocol. This means that the messaging layer needs to be wordy enough for the clients to be able to distinguish between the the parts of the message that is meant for them specifically and what is part of the message is really only meant for another client. XML fits that need fairly well. Long before XML became an industry buzz word, we used an XML like language called G2 to solve intersystem communcation problems between large disparate systems at a really big phone company. Some of the systems that we needed to connect together were built before 1969. Some were based on Unix solutions, others later on were based on Windows solutions. They all had to talk together, which meant that we had to have a language and machine neutral message protocol. G2 fit that bill. Now XML can fill that exact same need. It's not perfect, I'm not saying that it is. But what I am saying is that it fits a particular class of computing problem very nicely and should not be discredited simply because it can't be queried as nicely as a relational model. regards --Corey > Sorry, you're wrong again. I described a publish and subscribe mechanism > that broadcasts information only to those clients that have "subscribed" to > that particular publication. In your solution, every client interested in a particular > piece of information would have to query the server, essentially at the same > time, to retrieve it. Unless you can think of some way of throttling your clients, > I don't see how your solution would ever scale. You didn't prove that in my approach there is greater volume of information floating across network than in yours. How can you conclude that my solution won't scale, then? > Allowing clients to directly query the server via SQL makes your design > too fragile for real world application. Server side schema or application > changes will immediately break every client in your system. Your solution > requires that clients have intimate knowledge of the servers table structures > in order to properly formulate a "query" that would allow the client to pull > the information that they're interested in. No more than changing message format wil break everything in yours. Next, there is a concept of view. If you change your schema in incompatible way (note that it's not quite easy to do that; just adding the table column wont break anything) then you provide backward compatible views. > Interfaces between systems must form an abstraction layer between the > server and the client in order to insulate one from the other and to allow > for application flexibility. Views and query language work perfectly as an interface layer. The abstraction layer of relational language (unlike many on this group I include SQL there) is much higher than any alternative that you have in mind. > Not to mention, I don't know of too many application > owners that are going to allow untrusted clients to have direct database access [quoted text clipped - 4 lines] > with your stock information. Would you want external clients to be able to randomly > query for such information? Excuse me, but what about Database security? Unlike XML world database security matured for the period of what, 20 years already? If your DBA/Database designers aren't able to leverage database security mechanisms, maybe it's time to employ other ones? > > Sorry, you're wrong again. I described a publish and subscribe mechanism > > that broadcasts information only to those clients that have "subscribed" to [quoted text clipped - 6 lines] > information floating across network than in yours. How can you > conclude that my solution won't scale, then? I don't have to prove that. I think it's fairly obvious. Discrete messages are always going to be smaller than anything that you're proposing here. How can you control what you clients will query? What if they issue a select *? > > Allowing clients to directly query the server via SQL makes your design > > too fragile for real world application. Server side schema or application [quoted text clipped - 8 lines] > adding the table column wont break anything) then you provide backward > compatible views. Wrong again. That's the whole point of having an abstraction layer or a facade, if you want to talk in terms of patterns. If there's an abstraction layer in place, the receiving client never has to worry about what happens under the covers. In your solution, the client still has to be intimately familiar with the database layout or particular view that they need to query. > > Interfaces between systems must form an abstraction layer between the > > server and the client in order to insulate one from the other and to allow [quoted text clipped - 4 lines] > include SQL there) is much higher than any alternative that you have > in mind. Wrong again. Are you suggesting that the owners of the server should cater to every client by providing some sort of backward compatibility view? How many versions will they need to support? > > Not to mention, I don't know of too many application > > owners that are going to allow untrusted clients to have direct database access [quoted text clipped - 9 lines] > DBA/Database designers aren't able to leverage database security > mechanisms, maybe it's time to employ other ones? Ok, just for grins, why don't you call your bank and ask them if you can use your personal computer to query their customer database directly. I'm sure they'll be happy to have their database administrator work with you on a security solution that will allow you to query just your personal information. Do you see where I am going with this? Security should not implemented at the database level. It is implemented at the application and network levels. I'm sure some amount of security can be leveraged at the database level. But it will never be enough to support a real-world interface specification. With a publish and subscribe implementation (regardless of whether it's XML or not) My security concerns are far fewer than in your solution. All I need to know is that a trusted client has subscribed for information that my server is publishing on one or more topics. End of story. The client can be validated in any number of different ways. So, to wrap things up once and for all, let me just ask you if you have ever implemented your "you query my db and i'll query yours" solution in a real world application? My guess is no, because if you had, all of the real issues that I have posted in these last few messages would make sense to you. Cheers, --Corey > > You didn't prove that in my approach there is greater volume of > > information floating across network than in yours. How can you [quoted text clipped - 3 lines] > always going to be smaller than anything that you're proposing here. How > can you control what you clients will query? What if they issue a select *? FYI "select *" is full projection. If you are afraid of full selection, that is not the most resource intensive query, either. Hint: joins. Now, there is a way to limit resource usage in DBMS per each session. You can specify that a particular session can't exceed some amount of CPU resources, or logical reads. Irresponsible client will simply be kicked off the system. > > > Allowing clients to directly query the server via SQL makes your design > > > too fragile for real world application. Server side schema or application [quoted text clipped - 14 lines] > covers. In your solution, the client still has to be intimately familiar with the > database layout or particular view that they need to query. No, proceduaral/XML inteface layer is not higher abstraction than relational one. > > > Interfaces between systems must form an abstraction layer between the > > > server and the client in order to insulate one from the other and to allow [quoted text clipped - 8 lines] > cater to every client by providing some sort of backward compatibility view? > How many versions will they need to support? No more or less version # than in your approach. > > > Not to mention, I don't know of |
Enable EMail Alerts
Start New Thread
Reply to this Message