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:
- Personal information
- Bank details
At the same time, under personal information, we want the following information:
- Name
- First last name
- Second last name
- Age
- Vip customer
- Photograph
Finally, under bank details, we would have:
- Account holder
- Account number
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:
- NODE: Container node for other nodes
- TEXT: Text node
- URL: Node with a URL
- NATURAL: Node with a natural number
- INTEGER: Node with an integer
- RATIONAL: Node with a rational number
- NUMBER: Numeric node
- BINARY: Binary node
- HEXADECIMAL: Hexadecimal content node
- BASE64: Base64 content node
- BOOLEAN: Boolean content node
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:
- *: It means that there can be an indeterminate number of these children
- ?: There may be 1 or 0 of these children
- +: There must be at least 1
- number: There must be an exact number of these children
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:
- Name
- First last name
- Second last name
- Account holder
- Account number
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
- INTEGER
- RATIONAL
- NUMBER
NATURAL
We define natural numbers as any number greater than or equal to 0 without decimals.
The following are valid values:
- 0
- 132
- 5289423647623746237424242853987
- ...
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:
- -100
- +423
- 23874283
- ...
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:
- 1/4
- -10/8
- 238942598534/43253457438573
- ...
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:
- 19.27
- -2.75345e-20
- 1.432
- 12
- 2398754385734e-122
- ...
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:
- 1010100010
- 1000
- 1010
- ...
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:
- f52360Abcdef000
- 0012
- 3445
- 523a
- ...
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