Jim, JM> I do NOT believe that you are describing a "database language" that JM> is at the same level as SQL. I. First of all, i'm strongly disagree with you, because my _heterogeneus_ project consist of several ideas, quite different from each other, e.g. (1) rights for access on each record http://sql50.euro.ru/site/sql50/en/author/ddl_eng.htm (2) starting of record at selecting, i.e. "order by ... start by ..." http://sql50.euro.ru/site/sql50/en/author/dml_eng.htm (3) rough equality of strings http://sql50.euro.ru/site/sql50/en/author/rough_eng.htm (4) request into several databases simultaneously http://sql50.euro.ru/site/sql50/en/author/mc_eng.htm I already asked your opinion about them, but _regrettably_ you don't answer. That is strongly in riverbed of classic SQL. (5) JM> "to delete gaskets like php, etc." and "XML (actually HTML) JM> for i/o" DBMS must use at least one communication format, because it can't work without it (it's trivial). And if we force to use wide-spread format instead of proprietary, we remove gasket, which convert from proprietary format into wide-spread. Very sensibly. What's call surprise for you ? I want, that XML will be used even for traditional "select"-extractions ! (6) DBMS must use at least one communication protocal, because it can't work without it (it's trivial). And if we force to use wide-spread protocal instead of proprietary, we remove gasket, which convert from proprietary protocal into wide-spread. Very sensibly. What's call surprise for you this ? I suppose, that can be standardized without any surprise. II. What's about non-classic ideas: (1) use of XML itself as input code ! Laing into tables, using FK, instead of request into XML and then many "insert"s into different tables (please, forget about transport protocol now). Any line of code is superfluous. You disagree ? Why ? (2) sql-xml function give nothing new in comparison with "select '<tag field1= ' + field1 + ' field2=' + field2 + '/>" (let's name this as string-xml conversion) Both sql-xml function with decart production and string-xml conversion with decart production are greatly less convenient, then tree notation "a.b.c.d" both for profesional (because reduce labour) and non-professional programmers. (2.1) using mask *, ?, + (similar to mask in shell) to extract tree, i.e. tablename.*.tabname http://sql50.euro.ru/site/sql50/en/author/tree_eng.htm (3) JM> Calling your language "SQL5" could be JM> interpreted as saying "the next generation of the SQL language after JM> SQL4 (also known as SQL:2003)". This is actually next generation: wave algorithm. http://sql50.euro.ru/site/sql50/en/author/wave_eng.htm As you see, only tree (!) ideas are outside of streem of tradition. P.S. I must thank you for this letter, which moved me to regularize (re-build) this list of properties. >>P.S. Following real life, processing of tree in database is desirably, >>but not necessary. Removal of gasket is the main. _Different_ part of my project ecomonize the most time for different people (non-professional and professional programmers). What's about non-professional programmers, then they spend most time at adjustment of libraries of php, etc - as opposed to professional programmers, which spend most time to other points of my list. Thus I confirm my words: maximum benefits in whole _society_ will be brought by I.5, I.6 --- JM> I suspect that your language can be compiled into standard SQL. Excuse me, Fortran also can be compiled into assembler mnemonic, but it is a compiler instead of interpreter ! JM> I submit that you are actually defining a middle-ware language You think, that is something _can_ be realized as makeweight, then it's really makeweight. No, you are wrong. You forgot about usability. Applied specialists will be not capable to adjust middle-ware gasket, as well as php, perl and so on libraries. JM> I have asked around and talked to a number of database people about JM> your language. The response, 100%, is that nobody to whom I have JM> spoken believes that it is interesting to pursue as an extension to JM> (much less replacement for) SQL. Jim, if i can't turn even your attention at _different usability properties of old and new ideas_ (especially for II.1 and II.3), then it's follow to wait the same with other people. JM> P.S., I am astonished at your belief that the "market is JM> monopolized". If you mean "the database market", then I should point JM> out to you that there are three Very Large companies competing in JM> that space (IBM, Oracle, Microsoft), perhaps a dozen smaller JM> companies (e.g., Hitachi, Sybase, Ingres, Mimer), and at least a JM> half-dozen open source projects (e.g., MySQL, PostGresQL), all JM> competing with one another. Can you justify calling a market with JM> three Very Large companies (competing bitterly with each other) and JM> an additional 15 to 20 products (competing in various niches of the JM> market) as "monopolized"? That doesn't fit my definition of a monopoly! I count not quantity of DBMS, but quantity of people, using DBMS. I.e. i count by weight coefficients :) And i already say: any market has very less common with needs of people. --- >>(4) saving of accepted file (picture ) in any place >> (at least in filesystem) and to save HTML-link (value of @src) >> for file in record's field >>(5) sending of file upon HTTP-request according to @src >>applied specialists must thought-out scheme to avoid several FK >>from one table into other. This restriction may be overcame >>by plug-in for browser, which will send 'determination' >>http://html60.euro.ru/site/html60/en/author/forsql40_eng.htm >>http://sql50.euro.ru/site/sql50/en/author/determination_eng.htm >> content of file is invisible now in browser. >>To overcome this without programming (heavy for users), >>it's possible to install plug-in into browser >>http://html60.euro.ru/site/html60/en/author/inputpic_eng.htm Dmitry Turin SQL5 (5.4.1) http://sql50.euro.ru HTML6 (6.4.3) http://html60.euro.ru Unicode7 (7.2.0) http://unicode70.euro.ru Computer2 (2.0.2) http://computer20.euro.ru
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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