STxT: The Book

A language for the web

Chapter 4: Creating and Using Grammars

In this chapter we will explain the rules of document creation, from the point of view of grammars and namespaces. To do this, we will first consider how they relate to each other, and will then explain the rules of use and operation.

There are parts that may seem complex, but actually everything is very intuitive. It is much more intuitive than other technologies (I'm thinking about dtd’s, xml's, and xsd’s), but with a similar power.

What’s more, it is so simple that I think one chapter will be enough for explaining everything.

Attention, this is complicated; but worth it ;-)

When we are done you will almost be STxT experts :-)

Namespaces and grammars (*)

Let's differentiate between namespaces and grammars.

Sometimes we talk about grammars and namespaces interchangeably, although actually it is not "exactly" the same.

A namespace defines a set of nodes, with fully-defined rules. Grammar is not a document in itself, but would be created from one or more namespaces. When we say that a document must comply with the grammar, we are saying that all nodes should be correct, each depending on their namespace and definition.

Definition of grammar, as we understand it in STxT:

"Grammar is a cross definition of several namespaces, for a given document type."

For example: namespaces are:

-----------
Namespace 1
-----------
xxx: Node, should contain yyy,zzz,ttt
yyy: Text
zzz: Text
ttt: Node, should contain uuu of namespace NS2

-----------
Namespace 2
-----------
uuu: Text

The grammar for xxx checks that the xxx element has the following structure:

xxx:
    yyy:
    zzz:
    ttt:
        uuu:

Basic rule (*)

A document is valid if all its nodes are valid according to the grammar.

We know that an STxT document is a structured set of nodes, where each of them must belong to a namespace. Therefore, because of this we can also say:

A document is not valid if it contains any node without a namespace or it is incorrect

Well, this we already knew, and the best part is that this is almost automatic, as we do not need to give the definition for each namespace. We only need to specify the namespace of the first node, the following namespaces will be inferred from its grammar (or cross definitions of all the namespaces involved).

Finally, we can also deduce that

A node is valid if its content is valid

With this I want to emphasize that in order to verify a document’s validity we can go node by node, verifying their content. If all nodes are valid, that’s it. The document will be valid. This is why we will only have to focus on one node, and repeat the verification with each of them.

One example to start with

Let’s do an example, but now we'll go the opposite way as in the previous chapter. We’ll start off with the grammar in the document, we will define its nodes and characteristics, and finally we will create a test document.

Let's imagine that we have a gym, and we want a customer file. The personal information and bank details will go on this file.

Thus, a client will have two main nodes:

At the same time, under personal information, we want the following information:

Finally, under bank details, we would have:

Let's not complicate it any more, we have enough with this.

Let the party begin! :-D

How Namespaces are created and read

Creating a namespace is creating an STxT document with a specific structure and making it accessible on the web. This is important, since THIS DOCUMENT HAS TO EXIST.

The document must be a namespace definition (Namespace Definition), as is defined in:

www.semantictext.info/namespace.stxt

In our example, the document should begin thus:

Namespace Definition(www.semantictext.info/namespace.stxt):

# NAMESPACE: www.gym.demo/client.stxt
# Next will be the definition of each node of the namespace

....
....

The definitions of all the namespace nodes will be within this document.

Each node definition shall have the following form:

Node Definition:
    Type:
    Name:
    Alias:
    Description:
    Child:
        Node:
        Namespace:
        Num:

Let's break down each part:

Node Definition: Start of the node definition. Inside it, the following features must be specified: Type, Name, Alias, Description, Child

Type: is the node type. There are 11 node types, but the first 3 are the most important. It is mandatory to define the node type:

Name: is the name of the node. It is mandatory, and there can only be one. In addition, it cannot be repeated throughout the document, as there would be conflicts. This name is also called Canonical Name, to differentiate it from its possible aliases.

Alias: is a synonym for the name (Name), and there can be as many aliases as you want. But it has the same restriction as the name, that is, it may not be repeated, with other aliases or other names throughout the namespace.

Description: Here we give a description of what this node is, explaining it in a "human way". This is very useful, as it allows us to really know what a node is, and thus learn about the contents of an STxT document. This field is not mandatory, but is highly recommended.

Child: Specifies a possible child node. It must have the following attributes: Node, Namespace, and Num. This node can only appear if the node type is NODE.

Node: Name of the child node. It is mandatory to specify this information. It refers to the Name of the node (or any of its Alias). There cannot be two children with the same node name (including all their aliases), as the namespace could not be inferred automatically.

Namespace: Namespace of the child node. It is not mandatory to specify it, in which case it is assumed that it is from the same namespace.

Num: Specifies how many of these child nodes may appear. It is mandatory and can take the following values:

We will show you how we would start, with our example. In the next sections we will breakdown and finish off each part. It is quite intuitive, but it is worth lingering on the details:

Namespace Definition(www.semantictext.info/namespace.stxt):

# NAMESPACE: www.gym.demo/client.stxt
# A continuación irá la definición de cada nodo del namespace

# --------------
# Nodo principal
# --------------

Node Definition: 
    Type: NODE
    Name: Customer
    ...

# -------------
# Nodos básicos
# -------------

Node Definition:
    Type: NODE
    Name: Personal information
    ...

# -------------
# Nodos simples
# -------------

Node Definition:
    Type: TEXT
    Name: Name
    ...

Nodes of the NODE type

The node with the NODE type is perhaps the most important one, as it must always be present. It is a node that can contain other nodes, and there must always be nodes of this type. They are concept groupers, and make the entire hierarchical structure of STxT possible.

Let’s go to our specific example, and fill in all this content. We mainly have to say which children it can have, how many, and their namespace if it is different to the one we are defining (in our example it is not necessary).

...
...

# --------------
# Nodo principal
# --------------

Node Definition: 
    Type: NODE
    Name: Customer
    Child:
        Node: Personal information 
        Num: 1
    Child:
        Node: Datos Bancarios 
        Num: 1

# -------------
# Nodos básicos
# -------------

Node Definition:
    Type: NODE
    Name: Personal information
    Child:
        Node: Name
        Num: 1
    Child:
        Node: First last name
        Num: 1
    Child:
        Node: Second last name
        Num: ?
    Child:
        Node: Age
        Num: ?
    Child:
        Node: Vip customer
        Num: ?
    Child:
        Node: Photograph
        Num: * 
    
Node Definition:
    Type: NODE
    Name: Bank details
    Child:
        Node: Account holder 
        Num: ?
    Child:
        Node: Account number 
        Num: 1
    
...
...

That's it. We have defined all the NODE nodes in our document. With these nodes we can already see a little bit of the structure that it needs to have.

Summarizing, it would be:

Customer:
    Personal information:
        Name:
        First last name:
        Second last name:
        Age:
        Vip customer:
        Photograph:
    Bank details:
        Account holder:
        Account number:

Now we only need to define what the other types of nodes will be like.

Text nodes

We have already said that the most important basic nodes are the text ones. In fact, all basic types will be like the text ones, but restricting the values they can take.

We are now going to go over all the types there are, and apply them to our example.

TEXT

This type of node corresponds to text nodes, without any specific restrictions.

In our example, we would have most of the nodes:

These nodes would be like this inside the document:

...
...

# --------------
# Nodos de texto
# --------------

Node Definition:
    Type: TEXT
    Name: Name
    
Node Definition:
    Type: TEXT
    Name: First last name
    
Node Definition:
    Type: TEXT
    Name: Second last name
    
Node Definition:
    Type: TEXT
    Name: Account holder
    
Node Definition:
    Type: TEXT
    Name: Account number
...
...

URL

This type of node corresponds to a URL. It must be an absolute url, of the standard type used on the Internet. This type is also very important, as it lets us associate one document with another one available on the Internet. It can be used to reference images, websites, pages, blogs... or even another STxT document!

Valid examples:

Numerical Nodes

There are four types of numerical nodes, and they correspond to specific mathematical sets. We say this because STxT is not linked to any programming language, and has no restriction in terms of sizes or lengths. Programming languages often do have these restrictions; for example they need integers to be 32- or 64-bit.

Numerical nodes are:

NATURAL

We define natural numbers as any number greater than or equal to 0 without decimals.

The following are valid values:

In our example, the age field would be a natural:

...
...
    
# ---------------
# Numerical Nodes
# ---------------

Node Definition:
    Name: Age
    Type: NATURAL
...
...

INTEGER

We define integers as any positive or negative number with no decimals.

Valid examples:

RATIONAL

Rational numbers are numbers with the format aaa/bbb, where aaa and bbb are natural. We also accept positive (by default) or negative numbers.

Valid examples:

NUMBER

Numbers are the generic type for numerics with decimals, whatever their length. We use the widely accepted notation of using "e" to denote a 10 exponential, and "." as a decimal separator.

Valid examples:

Nodes with Bits

BINARY

The point is to use binary values, where it is only possible to use 0’s or 1's. We also allow blank characters or line breaks as separators.

Valid examples:

HEXADECIMAL

This node type is used for displaying binary values, but in hexadecimal format. We also allow blank characters or line breaks as separators.

Valid examples:

BASE64

This node type is also used for displaying binary values, but this time in Base64. Just like the in previous ones, we allow blank characters or line breaks as separators. This field can be used to contain complex computer data, such as files or images.

Example:

SGVsbG8gV29ybGQhISEhISEKSG9sYSBNdW5kbyEhISEhIUhvbGEgTXVuZG
8hISEhISFIb2xhIE11bmRvISEhISEhSG9sYSBNdW5kbyEhISEhIUhvbGEg
TXVuZG8hISEhISFIb2xhIE11bmRvISEhISEhSG9sYSBNdW5kbyEhISEhIU
hvbGEgTXVuZG8hISEhISFIb2xhIE11bmRvISEhISEhSG9sYSBNdW5kbyEh
ISEhIQ==

In our customer example we have the photograph as a field of this type:

...
...
    
# ----------
# Bits nodes
# ----------

Node Definition:
    Name: Photograph
    Type: BASE64
...
...

BOOLEAN

This value only allows for the display of one binary value: 0 or 1, so we also interpret it as a boolean (true or false) value. In the customer example, we will use it to specify whether a client is VIP or not:

...
...
Node Definition:
    Type: BOOLEAN
    Name: Vip customer
...
...

One example to finish off

OK, now that we've almost finished, we will see the full grammar, and a document example.

Grammar

Namespace Definition(www.semantictext.info/namespace.stxt):

# NAMESPACE: www.gym.demo/client.stxt

# ---------
# Main Node
# ---------

Node Definition: 
    Type: NODE
    Name: Customer
    Child:
        Node: Personal information 
        Num: 1
    Child:
        Node: Bank details 
        Num: 1

# -----------
# Basic nodes
# -----------

Node Definition:
    Type: NODE
    Name: Personal information
    Child:
        Node: Name
        Num: 1
    Child:
        Node: First last name
        Num: 1
    Child:
        Node: Second last name
        Num: ?
    Child:
        Node: Age
        Num: ?
    Child:
        Node: Vip customer
        Num: ?
    Child:
        Node: Photograph
        Num: * 
    
Node Definition:
    Type: NODE
    Name: Bank details
    Child:
        Node: Account holder 
        Num: ?
    Child:
        Node: Account number 
        Num: 1

# ----------
# Text nodes
# ----------

Node Definition:
    Type: TEXT
    Name: Name
    
Node Definition:
    Type: TEXT
    Name: First last name
    
Node Definition:
    Type: TEXT
    Name: Second last name
    
Node Definition:
    Type: TEXT
    Name: Account holder
    
Node Definition:
    Type: TEXT
    Name: Account number

# ---------------
# Numerical Nodes
# ---------------

Node Definition:
    Type: NATURAL
    Name: Age
    
# ----------
# Bits nodes
# ----------

Node Definition:
    Type: BASE64
    Name: Photograph

Node Definition:
    Type: BOOLEAN
    Name: Vip customer

The example

I hope that it is sufficiently clear :-)

# --------------------
# Customer information
# --------------------

Customer (www.gym.demo/client.stxt):

# --------------------
# Personal information
# --------------------

Personal information:

    Name: Shila
    First last name: Kween
    Age: 28
    Vip customer: 1
    Photograph:
        R0lGODlhlgCNALMAAFtepau07X2I1tvg+pOe42dwwMPK9vz+/AAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAACWAI0AAwT/8MhJq7046827/2
        AojmRpnmiqrmzrvnAsz3Rt3/Vg7MbgD7igsATUBQgCAYEQ2AGH0KGPR9XxAkd
        BIdl8Rr8qK3bJxJp5vosBmxQEvOA4yIhdvw/PonVt2OjIfXKCF1ZpPzsuA1hw
        g18DBDoVa0sde04bPQc9aY1Ra14+AUmQB00Se3RMO1h4lxisEoGdQgZMOrdKT
        wZKWW2jZUcBW25XmRaPEnezQZ8UvLFIvErAaKsFwb3RZZsSpAHLOM2nbhRLyh
        0CkXqTWkjmTQS1jOAwfBMD5BOitx/f86fBFJGJ9o3eDCT38nUzUxCDkR61qnG
        iwKfIGAGnDL7YdwohQCak/wh1mdJEgJ1gA0dOiveIjChZGlO07GgyVi1bFYws
        4WOsFJ5jq+os4QLSpBZXMU3g1OEGyJtteOiY0kAgw8ojmaykS7frEMykICa1w
        vkGW0V+HM61qgPnUcMD8dxMbfUVLAclfZqY6nEEiayeaUnWORY1pKYm1zBSQG
        t3AxlNB8hZGeqlbgamWeuGmjRSUToAHCVZbjxhV7we8b6VTV26AxpFrQ79mKg
        GibB4hEaTxlsK5FpVd2jnRLpwZIidopQ4BEwaD6RArJvUevtzOO1bokgoeiRw
        y79YzTNSclqr1CTmkkDdKsL3lOzZPxbfA4LkWlQ13+ndOu18EZ+5arhX3f9aO
        0BShB+RSIJHO5qMphs4f1TVRzxVCaXMP9zM5wpsHMQ3IHil5JIgUI3R8cNOQV
        1IHVAZUrAiYRpwUsBpws1n13RdMIHRIrglg94pP+oT44MClnINELoR2Yg5V3D
        1hzFr1GSdHy8WyUEgBhSwXX5BziIXPPLUMdcYOalF1WUf9AHENc9poKQcbgFD
        Y0R5aAFKeR5wGKAHfUyoyoNdDoKVGyDtMZcWBcgyAABVfdAoIR9MoYmWb+QHm
        Ua2+AWJam8EguijcM0YaZUfIvhDolVZ+uYXPA20yWCTFgAATADMSGpO6aTQ5w
        FsXuqQpXH4Nw1s8qhZ6xblEAqqm0xY5Qf/lpBxMSIGq0rRhShH+HREGrcxSsG
        Mpr2ZHLVmVgBLGmtc0+Key4w0LA9c4TEjg8kQY1SHtv3DXwbK3beDG+lYOm0j
        fQ5gq3n4RDuKqPIKZacf8y47nTgXaNHaDjNKeN8Ft8aRLikVdirMwoohxM6MA
        meca0dhkroFtEYugZ2z9GDBsGqbFKDzLigbXFAZoOmGz7z2xVISZhhsUVAkps
        m8MiHAfsFEoq1EpgnAkGjxjV80ARAvx0nMmGgaXD3XrwWMNtQn1mdTW7NHmVR
        lTgG9qdJ2N7PWGJkSShz5Bt1UvFQquIFMAXA7qtZc9DeIJGrfS39aMLJPktiG
        dRkGnqfc/1yLluUePgbXuqzkNUupWksEaOmDSSzNE/qu5Wg6dVyI4LMjMY8aw
        Kgim6C2qM6jK7iM7ezBhc+4faQj4T9h++rZnzt4LQy6uCFGeSmg5ZgdE4y+HG
        PUUpiEpA86HgWZXr6aaxvlR7zMOM9JUE/TzMJEtA9IOif3oN4ec7NJG8iKW67
        +oYhraEkxovBOn5Kjrs9x4jnSwYumHiGrrTBsOcuonU/csQWNhWg98qnPFrwW
        ilEQC36wmJS3xrKLYCQjMjoA3vPywz8wmMIpkYmG6irVFUJJQ2e10gIAalWgJ
        OTFPMCrCT4Ylbqm9GUapHhSAERXxCSBTwgsSYbBtBC/nv8gRlYvi0iWwDhERv
        HthcnTUjJIiAc2eE0uGXuVjt4IidQFD0SzOFcvuHA9CsoKNAUUBmKm0TdZNWp
        XyBLGrFoDEDC6r43RKKM7zOG2ZSylFjo7in8SCEYRirBWQ4xkEwl1E7HVygzS
        kkQZs+UcIB7LiPEjUQZ/Yg2AXWoXQuwb3wbiyCB6TV3TmVoZC1lGUPqilxISQ
        DHB9SXXXZEWUUkO3xjXG51Z85ep0eEydQY6gdRCmdyES1+G8ccOouiToGTUhF
        hpgWoJwSmIItoVhgLETLqjDWcoptf0yU9ftMNyZawnokTHN6V5pkodY1Xqisn
        FSxUQjErURhLukbo/pvP/WNZMoncYyIsKKnOILzNi6hrSwOGAA5NbyORHkXW1
        UBqobrsgIkWSAFJEhU1rypzGGLFZL41y8zRUk8AzcvLMcNTnnjMqJtB+qYz6d
        FQxH+Ei69JVT87sNEuyGOUdOjU0tcXSRcNjx7byRxSbKjNzRiJnUEtREkrtK5
        6NautRcOMZrTXoOaFjo8HWisdG1OGAPVAXJeRlyCH6o30FDZp0ssS6vWhiCUn
        8Qz1nhZppoOSQaxhmMi5YiqLeYJxmQIJAHoUkYWJkOhRUZnB4JooeqYkvBK2o
        Ma3RQVupjR1DzIvFGNmJhGXpsnBRjofwQQCQ3qS1ycnCy9gIIsmGsoJA/5yGd
        /J3vQaNc4hWUKMmPGuD83gtLqqZKDai8dHnZswd7fvbUdAFnqGBVKmI+pf4nm
        YegNXzb/5wJw6e0sRdlGdcyVCJImtaOZuZkSIg2mlAbUXI54wOvBVFVBa2e1K
        MnZJSIeoRkNgyYNHphaaaRfCAEnvKUdaEneVoYROdilX9GjV0bfBJljRcpoES
        cShCHCJUGcmPOJU3iE9o1jHSYUA7phSXGmlDEHckr4DFKJ5GWUJAIVXAe3yCd
        5zgDrVod+SdJTAmWvKoT4gXNaceq6YYajJ1FnGPbWVAFfPiImhyKCVwjEF3O4
        uEncBH0056xyFGupvRLkJD1gHslxjhjv9HwJG1zAJzb4hAhxDB9b2+GQZSbrL
        gFFPqFCPsuBOI8G9xsxdcAF2G0JH+FRdpLIKXKG2fneYdqwV1CztUEDVcC8Fi
        LxND85VgbkoIJYUjIeTeFqy+OnaLoF0za/mErVx8QumoE60m7FxaEKkqnHKZ2
        L4XkO27LtaibGvVRmpGK6FBINZibsNYbXh7b5w9ju3KuIpag2ewgkpVVPo00p
        GNjLuAjsW8AW5dEA9rD5/jaxxe2pKCtLuDbSC4+pAkDJaOoCrBJugTPCfwZUO
        BFfKFie1CykcUtDZWRRNBESP8NDS0kbiDMJAb/ryYZ+NY4vq4RsUtLoKpzXxn
        ssCGeXz/IwdTTDNLF5jaG1iHgnaHLdyPta81E7SdNTRILjgPQ2oAhkkMbaNNJ
        thrf0vAhbB10BjBkRBn0D2DRUBxKNfWxx9gMzAQqLRU/dhlELmJZX5H5RF4ig
        Lvyr4Tha/bDJ2FOgvxXgnLqhV6tNwE+WAFBR0Ng0LT04AguWL1EnSB8X4widj
        EJg2cuOe1tlB80xM4CrjQbgOj4FTY2XscNigtuVk4Ryjosq8hQNagDGmWZZyS
        yQWdgPZ5ss0wRssLdv8lv6iFwiO4KBRFIB49U6jo1nDuBOnk4dR9G4M5QKLeB
        PuDKZ8XAutDu13fWF3khssfijvEu5Vc8/IiYaDVvW+H/8AqpnBRZAd1VwPRYA
        fLgw/vh3iGMAVjFCXgw0k55koCxQhVd1RclQlUwDPftx2xwRrMQBTyoA4UokW
        RcFhFUFHRACwFJFWIJX5clAeX8E1cAxF6sAgJ5HA8cT6bonoXB0XigyVP0Q1I
        0iBw0XHWtGgHshjpQhQiKAoyxTsAIUEdiCUwZ0cr8xToIx0plAPSQA63lTCd9
        XdH8xPtwyZxlxN2Q35lGBKV0Q5bVUfP9wmiNRV50QWboCP7ZXmb4iKrczpD+E
        3QQk+M1ReUR1HjdoSaUXFygUs74SKq4HpCWDV7kQpZBwJkED9rdlDWh0OTAi0
        toTW1AnjpNxzlQy8ukv9RidFBZrJYDXcY6/YqgHgDhuYKntKHBaILV0N3QKAs
        ZocoW5ITpUEcC4JRBiQ9UNMpttEoy5J6F8F2TecqxfNY4iQh+uYpbbI2xjNQU
        vUqIqYHbQZSZCRTbvMzlFQbeTEQNiBNoXYgokVJoCNwcPEa5QZ4ObZSkQMQVb
        cKEahP9NVOCcI3o4GAkIRvM4BPBfNNbAIRaiId4PEUxCIQ9fdjxqQXVIAiKKV
        j+pRq+DEVCURDC/kYNFBxPdIdP/VyTjEYecEXtbN0dABO4DhM5mRmyxRQEwUo
        VjM/mgckXdF2nNZIbdB5kHGOrPAQxsM4yJhdFqVP5wVi7wWTB/RSVhH/eDEEA
        m4WA4yYXyuWL/egg2RBV3t4B5TASTNpURnFT0e2FaNojqd4HDyoeW1ACrjkQm
        mGStCALhcoVKrhSkqZlAFlR2w0FKYmOS03UXCCItsSJfLgJv0hZPGyHeaGgL9
        TllLWlEw0CisUXGUQI9nhHsIgCH/xHw6JIBlGhqzkH9WBgEC0KKsWEN9kdnMG
        JLywPwpBfLOgkjPhGmtRGilUFhOhA8dSgFcjDRhTKIthO1t4DHSzlZtJMNXjj
        NVGKvuXPuCWDg0xFAK4HFzwIOyUBos2CLAYFviYAbuWByTULFrWikPyJVShHu
        I0PNA2JLFxattVOF4DQ6UBkghiWWdi5SOBGQdapnLbdSumUCnYozxEYDsKIUs
        CopFw4oyEoSTIYB6hsj7aIYOfVpz40VthB5Ru8lpjRAxEECW5EAI1FB4bwwGH
        pIgl+iy/dYZuUokmWjXYoy44t3SmEaNgkCVBcwLfIBf9iKM4UFxywaOu50JAO
        gT/xINaUUcOeqS6AjwuaomD+J5OCgNveUckajccWKU0EBdDlQKMIz5c2nbWF6
        UjoDYwOqZbdhItEChqqitG4IotYG5v6gLpx6Aygad1aqd72qd++qeAGqiCOqi
        EWqiGeqiImqiKuqiM2qiO+qiQGqlyEAEAOw==

# Note: If someone wants to amuse themselves, the photo has been
# drawn by me. You will realize that I am quite better as a 
# computer tech than as an illustrator :-D

# ------------
# Bank details
# ------------

Bank details:
    Account holder: Joan Costa Mombiela
    Account number: 0000-0000-00-000000000

The end. Did you like it?

One last thought (*)

Is entering the name of the grammar version a good practice? As for example xxxx_1.0.txt?

It depends on each case, of course. Is the document final or is it expected to undergo changes?

An interesting option is to have a document without version that is always updated, and keep untouchable documents with version numbers. This is a hybrid solution which I think is correct for many cases.

Grammar of the grammar (**)

A document only makes sense if it has the grammar first. But in order to define the grammar we have to make a document :-O With this we have a recursive problem, so that the definition grammar must be implicit and very well known. This document is public, but must be inserted in a general way in all the grammar parsers, as initial grammar.

I introduce you to the grammar of grammar. You will see that throughout the chapter we have used aliases, as they seem clearer than canonical names. Even so this is indifferent, as names and aliases act as synonyms.

To summarize, we have the following elements:

ns_def (namespace definition):
    n_def (node definition, node def, node_def):
        cn (name, node, node name, canonical name):
        a(al, alias):
        type (node type):
        dsc (descrip, description):
        ch(child):
            cn (name, node, node name, canonical name):
            ns (namespace):
            n (num):

I introduce you to the grammar of grammar, in its full splendor:

ns_def(www.semantictext.info/namespace.stxt):
 
n_def:
    type:NODE
    cn:ns_def
    a:namespace definition
    a:namespace_definition
    ch:
        cn:n_def
        n:+
n_def:
    type:NODE
    cn:n_def
    a:node definition
    a:node def
    a:node_def
    ch:
        cn:cn
        n:1
    ch:
        cn:a
        n:*
    ch:
        cn:type
        n:1
    ch:
        cn:dsc
        n:?
    ch:
        cn:ch
        n:*
n_def:
    type:NODE
    cn:ch
    a:Child
    a:Child Node
    ch:
        cn:cn
        n:1
    ch:
        cn:ns
        n:?
    ch:
        cn:n
        n:1
n_def:
    type:TEXT
    cn:cn
    a:name
    a:node
    a:node name
    a:canonical name
n_def:
    type:TEXT
    cn:a
    a:al
    a:alias
n_def:
    type:TEXT
    cn:type
    a:node type
n_def:
    type:TEXT
    cn:n
    a:num
    a:occurs
n_def:
    type:TEXT
    cn:dsc
    a:descrip
    a:description
n_def:
    type:TEXT
    cn:ns
    a:namespace
This website uses cookies to ensure you get the best experience on our website. [cookies.html|Learn more] Got it! More info