UA-spec (text)

Dear Sir or Madam,

	I want to propose to your consideration Uniform Abstract Language. It is the language for platform- and application-independent data transfer. Text file of specification is attached to this message and html version is:
	http://lists.w3.org/Archives/Public/www-talk/1999JanFeb/0011.html

Sincerely yours,
     Yuriy Guskov.

____________________________________________
The solution to the problem 
changes the nature of the problem.
Uniform Abstract Language (UA)
Specification Draft
Abstract
The Uniform Abstract Language has been designed for ease of organizing and interpretation of various forms of data. Its goal is to make portable any form of data, code, definition, and variance to be processed on the Web.

Table of Contents
1 Introduction
  1.1 What the UA is
  1.2 Notes
2 Documents
  2.1 Characters
  2.2 Common Syntactic Constructs
  2.3 Comments
  2.4 Prolog and Expression List
3 Elements of definition
  3.1 Operations
    3.1.1 Disjunction
    3.1.2 Conjunction
    3.1.3 Junction
    3.1.4 Subjunction
  3.2 Contexts
    3.2.1 Quantitative context (values)
    3.2.2 Abstract context (names)
    3.2.3 Relational context (types)
    3.2.4 Modal context (modes)
Appendices
  A. References
    A.1 Normative References
    A.2 Examples
      A.2.1 Hypertext table
      A.2.2 Programming
      A.2.3 Query (SQL).

1 Introduction
Universal Abstract Language, abbreviated UA, describes structure, abstract interpretation of information as well as its relation meaning and modal organization of the data.

UA documents are made of value. Structural elements are associated with the help of operations and are considered in different contexts.

1.1 What the UA is
The UA is structural language for information transfer over the Web. 

The design goals of UA are: 

UA shall be compatible with any form of data, code, definition, and variance. 
UA shall provide information transfer not depending on platform and implementation (application). 
UA shall provide structured environment of information for applications. 
The number of optional features in UA should be zero. 

1.2 Notes
There are several notes on issues that stem from the UA design goals:] 

UA is not compliant with any language or technology. Any compatibility comes through defining this language with the help of UA constructions and assigning them specific values of this language. 
As UA is strictly and well structured language it is strictly and well visualized. 

2 Documents
Each UA document consists of value. Structural elements are associated with the help of operations (disjunction, conjunction, junction, and subjunction) and are considered in different contexts (structural, abstract, relational, and modal).

A textual object is an UA document if taken as a whole, it matches the production labeled document.

Document 
[1]  document ::=  prolog ExprList 
 

2.1 Characters
A structural elements contains text, a sequence of characters, which may represent value or identifiers. A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646]. Legal characters are tab, carriage return, line feed, and the legal graphic characters of Unicode and ISO/IEC 10646. The use of "compatibility characters", as defined in section 6.8 of [Unicode], is discouraged.

Character Range 
[2]  Char ::=  #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /*  any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ 
 

2.2 Common Syntactic Constructs
This section defines some symbols used widely in the grammar.

S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs.

White Space 
[3]  S ::=  (#x20 | #x9 | #xD | #xA)+ 
 

A Value is a token beginning with a letter or one of a few punctuation characters, and continuing with letters, digits, hyphens, underscores, colons, or full stops, together known as name characters or enclosed with quotation marks.

Values and Operations 
[4]  Value ::=  ((Char | '_') (Char)*) | '"' (Char)* '"' | _ 
[5]  Op ::=  ('-' | ';') | ('+' | ',') | ('*' | '.') | ('/' | ':')  
 

2.3 Comments
Comments may appear anywhere in a document.

Comments 
[6]  Comment ::=  '/*' (Char)* '*/' 
[7]  OneLineComment ::=  '//' (Char)* 
 

2.4 Prolog and Expression List
Prolog defines imports for a document. Document expression list must appear after prolog.

Prolog 
[8]  prolog ::=  ('import' Value S)+  
[9]  Expr ::=  ExprList (Op ExprList)* 
[10]  ExprList ::=  '[' Expr ']' | '(' Expr ')' | '{' Expr '}' | '<' Expr '>' | Value  
 

3 Elements of definition
3.1 Operations
Operation is the way of assembling values in associations. Also an operation may define value's disposition to associating in specific way.

3.1.1 Disjunction
+---+         +---+
|   |         |   |
+---+         +---+
       +---+
       |   |
       +---+
  Disjunction represents structural elements as independent. (single)
"A - B" means "A is independent from B".
 

3.1.2 Conjunction
+---+  +---+  +---+
|   |--|   |--|   |
+---+  +---+  +---+
  Conjunction represents structural elements as a group. (general)
"A + B" means "A is grouped with B".
 

3.1.3 Junction
        +---+    
   +----|   |----+
   |    +---+    |
+---+     |    +---+
|   |-----+----|   |
+---+     |    +---+
   |    +---+    |
   +----|   |----+
        +---+
  Junction represents structural elements as an association. (plural)
"A * B" means "A is related to B".
 

3.1.4 Subjunction
        +---+
        |   |
        +---+
          |
  +-------+-------+
  |               |
+---+           +---+
|   |           |   |
+---+           +---+
  Subjunction represents structural elements as a tree. (total)
"A / B" means "B is part of A".
 

3.2 Contexts
Any information could be considered in four contexts: quantitative, abstract, relational, and modal. Each context do not define information but the interpretation of it. Examining different contexts, we take this document as example.

3.2.1 Quantitative context (values)
Quantitative context used for: 

organizing data in the most convenient and appropriate way; 
exposing organizational links between parts of data; 
constructing alternative complexes of data. 

For example, this document "ua-spec" can be divided in the following values: abstract, intro, defs, and examples (each of them could represent either a hypertext document or a part of a document) 

value  
[value1 - value2]  Used for separate values.  
[abstract - "ua-spec"]  In this case abstract may be viewed instead of full specification ua-spec and vice versa.  
list  
[value1 + value2]  Used to express unity of several elements.  
[abstract + intro]  Here, abstract, intro etc originally are pieces of hypertext results in the integral document.  
graph  
[value1 * value2]  Used to show dependencies (links) between various values.  
[abstract * intro]  On the contrary to the previous example, if we want to represent abstract and intro as dependent but separate values we use junction operation.  
tree  
[value1 / value2]  Used to convey hierarchical constructs within a single value.  
[defs / "op-def" * "context-def"]  op-def and context-def compose defs which can be either imaginary unity of them or a single value (document or part of document).  

3.2.2 Abstract context (names)
Abstract context utilized: 

interpreting and explaining information; 
make possible to treat information in different ways (eg, allow an user change some properties of it). 

This document could be divided into two names base (consists of abstract and intro) and desc (consists of intro and defs). 

(base) [abstract (desc) [introduction] (base) defs] (desc) or
(base) [abstract introduction]
(desc) [introduction defs]


Let's examine various variants of associating these two names with the help of different operations. 

element  
(name1 - name2)  Used to interpret names that are independent by values included in it.  
(base - desc)  Two names treated separately and can used for representation for beginners which make accents only on key items.  
item  
(name1 + name2)  Used to interpret a line of names which set up the whole.  
(base + desc)  Names, taken as the whole, represent common or thorough view of this document.  
unit  
(name1 * name2)  Used to explain several names result in an unit.  
(base * desc)  Such a representation can be used for concise expression of the document's meaning.  
symbol  
(name1 / name2)  Used to explain a value hierarchically structured.  
(base / desc)  This form conform standard building of specification and can be used for formal purposes.  

3.2.3 Relational context (types)
Relational context used for: 

serializing parts of information; 
building base structures for further extending. 

Description of operations in this document can be typified like that: 

<"ua-operation"> : ( desc + "desc-img")
<"ua-operation2"> : (desc + "desc-aux") * "desc-img") 

We will examine various variants of associating these two types with the help of different operations. 

object  
<type1 - type2>  Used for static representation of information.  
<"ua-operation" - "ua-operation2">  "ua-operation" and "ua-operation2" associated by disjunction can be used separately.  
action  
<type1 + type2>  Used for dynamic representation of information.  
<"ua-operation" + "ua-operation2">  Type changing results in an action that is conjunction of two or more objects.  
entity  
<type1 * type2>  Used for analytic representation of information.  
<"ua-operation" * "ua-operation2">  "ua-operation" and "ua-operation2" are linked as related to each other by some information ties.  
principle  
<type1 / type2>  Used for synthetic representation of information.  
<"ua-operation" / "ua-operation2">  "ua-operation" is a principle relating to "ua-operation2". Principle can be used excluding specific implementations. That is, "ua-operation" expresses principal construction consisting of description and image that can be applied to another information.  

3.2.4 Modal context (modes)
Modal context used for: 

variating information; 
constructing manifold complexes of information. 

This document could have modes "ua-html" and "ua-java". Let's examine various variants of associating these two modes with the help of different operations. 

mode (possible)  
{mode1 - mode2}  Used to express sole variation of information.  
{"ua-html" - "ua-java"}  Here, we could choose from two modes of the document.  
variant (probable)  
{mode1 + mode2}  Used to show several variations that integrated in a representation. It is definition by examples.  
{"ua-html" + "ua-java"}  But here a browser should know about two variants of documents. Each of them is an exception as related to each other.  
parity (arbitrary)  
{mode1 * mode2}  Used to provide information with simultaneous variability.  
{"ua-html" * "ua-java"}  In this case, ua-html and ua-java and two modes which, in general, can change each other.  
goal (necessary)  
{mode1 / mode2}  Used to form parts of information that is inducible from another ones.  
{"ua-html" / "ua-java"}  One mode is subgoal for the another.  

--------------------------------------------------------------------------------

Appendices
A. References
A.1 Normative References
ISO/IEC 10646 
ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (plus amendments AM 1 through AM 7). 
Unicode 
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996. 
A.2 Examples
A.2.1 Hypertext
This document  <text/html> (Introduction) 
["
<p>Universal Abstract Language, abbreviated UA, describes structure, ... 
"];
...

(Introduction) +
(Documents)
("Elements of definition") / (
  Operations /
    (Disjunction *
     Conjunction *
     Junction *
     Subjunction
    ) 
  +
  Contexts /
    ("Quantitative context (values)" *
     "Abstract context (names)" *
     "Relational context (types)" *
     "Modal context (modes)"
    )
)
...
  
Documents with the same header and footer. For a browser result of adding header, body and footer is a single document. But also a browser treat each of these parts separately that as the result diminish traffic and eliminate unnecessary routine (composing the similar documents, updating all similar documents).  <hlink> (header) ["header.html"];
<hlink> (main) ["main.html"]; 
<hlink> (footer) ["footer.html"];

(header + body + footer)
  
<table>
<tr><th rowspan=2>col1<th colspan=2>col2
<tr><th>col21<th>col22
<tr><td>val11<td><td>val12
<tr><td>val21<td>val22<td>
</table>
col1 col2  
col21 col22  
val11   val13  
val21 val22    
 (col1 + col2)

[val11 + _ + val13]
[val21 + val22 + _]

or

[(col1) val11 + (col22) val13]
[(col1) val21 + (col21) val22]
 

A.2.2 Programming
interface AIntf {
  int field1;
  int field2;
  int method1(int param1);
}

class AClass implements AIntf {
  int field3;
  int method1(int param1) {
    if (param1 > 0) 
      result = 1;
    else
      result = 0;
  }
}
/* ...and some structures which might exist. For synchronization, content of a storage with knowledge and content of objects in any programming language.*/ 
entity AnEntity {
  int attr1;
  int attr1;
}
 <AIntf> (/(
  <int> (field1) *
  <int> (field2) *
  <method1+> (<int> param1 * <int> result)
  )
)

<AClass> (
  <AIntf;> *
  <int> (field3) *
  <method1+> (<int> param1 * <int> result) [
    </> ((param1) < ">" > [0])
      [(result) [1] -
       (result) [0]
      ]
  ]
)

<AnEntity*> (
  <int> (attr1) *
  <int> (attr2)  
)

<AClass> [<AnEntity*>] /
  (field1) [(attr1)] +
  (field2) [(attr2)]  
)
  
try {
  i = i / j;
} catch (ArithmeticException) {
  i = 0;
}
 { 
  (i) [(i) / (j)]
} - 
{
  "AritmeticException" 
} <+> [ 
    (i) [0] 
]
 

A.2.3 Queries
select * 
from customers
where customers.name = 'Henri'
Such query conformed to UA form can be used throughout all applications recognized UA. Moreover, this entity can be used not depending on migration over different application. Eg, at first an entity could have form an appropriately structured text file then a simple database then an SQL query and so on.  (customers / _)
</> (customers / name) ["Henri"]
 

--------------------------------------------------------------------------------

Copyright c 1999 by Yuriy Guskov. All rights reserved.

Received on Tuesday, 2 February 1999 07:33:06 UTC