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.
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.
The UA is structural language for information transfer over the Web.
The design goals of UA are:
There are several notes on issues that stem from the UA design goals:]
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 | ||||
|
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 | ||||||
|
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 | ||||
|
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 | ||||||||
|
Comments may appear anywhere in a document.
| Comments | ||||||||
|
Prolog defines imports for a document. Document expression list must appear after prolog.
| Prolog | ||||||||||||
|
Operation is the way of assembling values in associations. Also an operation may define value's disposition to associating in specific way.
+---+ +---+
| | | |
+---+ +---+
+---+
| |
+---+
|
Disjunction represents structural elements as independent. (single) |
+---+ +---+ +---+ | |--| |--| | +---+ +---+ +---+ |
Conjunction represents structural elements as a group. (general) |
+---+
+----| |----+
| +---+ |
+---+ | +---+
| |-----+----| |
+---+ | +---+
| +---+ |
+----| |----+
+---+
|
Junction represents structural elements as an association. (plural) |
+---+
| |
+---+
|
+-------+-------+
| |
+---+ +---+
| | | |
+---+ +---+
|
Subjunction represents structural elements as a tree. (total) |
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.
Quantitative context used for:
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). |
Abstract context utilized:
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. |
Relational context used for:
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. |
Modal context used for:
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. |
| 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) [val11 + _ + val13] [val21 + val22 + _] or [(col1) val11 + (col22) val13] [(col1) val21 + (col21) val22] | |||||||||||
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]
]
|
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"] |