Entering of XML without writing SQL-code

Entering of xml-data by operator 'insert' is already considered in separate document. If we allow entering of xml-data as well as sql-code, then we remove gasket, which surround xml-data by operator 'insert'. This is very actual, because applied specialists, automating own activity without programmer, can not adjust libraries of such gaskets as php, perl, etc.

Triggers are waked, beginning from root record of tree.

• sender address in literal form, e.g. "asker.org"
• sender address in numeric form, e.g. "111.111.111.111" (for case, if sender has no literal address)
• sender TCP-port, e.g. "80"
• receiver address in literal form, e.g. "distination.org" (for case, if database serves several receivers)
• receiver address in numeric form, e.g. "222.222.222.222"
• receiver TCP-port, e.g. "80"
• if transfer protocol allows, then also
• receiver username, e.g. "tomson" (it's the same, which is specified in browser's string "/~tomson")
• receiver service (script), e.g. "car-celler" (it's the same, which is specified in browser's string "/cgi-bin/car-celler.cgi" - path and extention of file are ignored, existance of services with identical names is impossible)
• user agent (browser name)
• sender username

• sal (sender address literal, i.e. sender DNS-address)
• san (sender address numeric, i.e. sender IP-address)
• sp (sender port)
• ral (receiver address literal, i.e. receiver DNS-address)
• ran (receiver address numeric, i.e. receiver IP-address)
• rp (receiver port)
• if transfer protocol allows, then also
• ru (receiver username)
• rs (receiver service)
• g (user agent)
• su (sender username)

Field 'sender username' in root record is intended for future version of HTTP: receiver must react individually to each concrete user-sender, therefore it's possible to expect transfering of sender username too.

Dmitry Turin