[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SQL5 (was: SQL4)

• From: Dmitry Turin <sql4-en@n...>
• To: xml-dev@l...
• Date: Mon, 1 Oct 2007 20:38:19 +0400

Jim,

JM> I fear that your choice
JM> of that same name for your effort might confuse some people and give
JM> you less attention that you might want (because people might assume
JM> that "SQL4" means "SQL:2003").
Name "SQL4" was changed to "SQL5" after your note.

JM> More importantly, it seems like you might not be aware of SQL/XML,
JM> part 14 of the SQL:2003 standard (revised in 2006, with another 
JM> revision of the whole SQL standard expected in 2008).  SQL/XML 
JM> (ISO/IEC 9075-14:2006 and ANSI/ISO/IEC 9075-14:2006) provides 
JM> language to transform SQL tables into XML trees and vice versa
SQL/XML requires many hand's (manual) job for programming:
it does not put and extract tree automatically (in opposite to TML, which use FK for this).
Besides SQL/XML has no other features, like processing of trees (including wave algorithm),
automatical input and output BLOBs (pictures).
It seems to be impolite to duplicate whole list from letter to Jonathan.

JM> If I understand your work correctly, the significant difference
JM> between SQL/XML and your language is that you use foreign key 
JM> relationships implicitly to perform joins, using the notation 
JM> T1.T2.T3, which is roughly equivalent to ((T1 JOIN T2 ON T2.FK=T1.PK)
JM> JOIN T3 ON T3.FK=T2.PK).
You describe difference right,
but this difference is particular property of whole construction.

JM> My conclusion about your work is that you have done two things:
JM> You've chosen a non-SQL-like notation to express SQL constructs (in
JM> SQL, a.b.c means "column c of table b in schema a", but it your 
JM> syntax is means "join tables a, b, and c based on their PK/FK 
JM> relationships")
I foresaw this: a.b.c inside SQL-statement means one,
but in the begining of the statement means other.
Where is the problem ?


JM> and you've mixed
not mix, but join

JM> ... in at least one completely
JM> orthogonal concept -- the network protocol that a client application
JM> might use to connect to a DBMS.
DBMS does not exist without network protocal _at all_.
Client must use at least any protocal,
otherwise DBMS will not capable to communicate !!
So let's client use protocal (not HTTP) wholely, up to bottom !

JM>   I think that the former, however 
JM> compact, is a fatal error in the SQL community
Give, please, some arguments for this point.


JM> more properly the domain of a database system
JM> implementation than a database language.
I don't understand, explain please comparison of
'domain of DBMS' and 'database language'.

JM> it seems very UNlikely that either SC32 or INCITS would be interested,
JM> because they already publish a standard that accomplishes what you
JM> say is your primary focus.
(1) What is the name of project (standard) ?

JM> In summary, I regret to say that I do not believe that you've come up
JM> with anything sufficiently new to overcome existing standards
New is not in particularity:
new is in integral characteristics, in features of wholeness.

  Keld Simonsen (keld@d...) and Gerald Radack (Radack@c...)
from JTC1SC22 advise me to contact with you:
KS> There is a gyu Jim Melton who has been working with
KS> SQL for years. Try to contact him, Sybase is the company, I think.
+
RG> I suggest that you contact Jim Melten (jim.melton@o...,
RG> jim.melton@a...). See his biography at
RG> http://books.elsevier.com/us/bookscat/authors/defaultindividual.asp?coun
RG> try=United+States&authorcode=108707&community=&mscssid=3NGWE388S
(2) Help me to collect interested people of SC32, SC22 and maybe from
Sybase and Oracle.

JM> I also am sorry to tell you that X/Open no longer exists as an
JM> independent entity.  About a decade ago, perhaps a little more, 
JM> X/Open merged into The Open Group, which terminated all of its SQL
JM> activities.  For a few years, discussions were held with The Open 
JM> Group about some SQL-related activities (e.g., conformance testing),
JM> but they were clearly uninterested unless there was a lot of money
JM> given to them up front.
(3) Thank you.
Has www.ansi.org itself WG or mailing lists ?

---

Please, say your oppinion about
(4.1) access right for every (in potential) record
http://sql50.chat.ru/site/sql50/en/author/ddl_eng.htm
(4.2) 'start by'
http://sql50.chat.ru/site/sql50/en/author/dml_eng.htm
(4.3) rough equality of strings
http://sql50.chat.ru/site/sql50/en/author/rough_eng.htm
(4.4) request into several DBMS simultaneously
http://sql50.chat.ru/site/sql50/en/author/mc_eng.htm

---

JM> It seems that you know that ISO/IEC JTC1/SC32 is responsible for data
JM> management, and you must know that includes SQL.  It is true, and 
JM> very regrettable, that Russia never participated in SC32.  Russia has
JM> been an Observer member of SC32 for several years.
and also never in SC22 (except SC22/WG21 for C++)

JM> The closest that SQL provides is the relational operator
JM> NATURAL JOIN which depends on columns that have the same name in two tables.
Russian forums have compared TML and 'natural join'.
'Natural join' is un-convenient during changing of code -
but this is particular note, because it's impossible to build
new integral property upon 'natural join'.


Dmitry Turin
SQL5      (5.4.0)  http://sql50.chat.ru
HTML6     (6.4.2)  http://html60.chat.ru
Unicode2  (2.1.1)  http://unicode2.chat.ru
Computer2 (2.0.3)  http://computer20.chat.ru