Re[3]: [xml-dev] SQL5

[Dmitry Turin <sql4-en@narod.ru>]

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 [2]) 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
>>[2] 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