Property is the most basic element of TemlCode internal syntax. It is the placeholder for definitions.

Syntax of Property Tag

~< Parameter [ ";" Parameter ";" ... ";" Parameter [";"] ]>

Character	Name	Code Point
;	SEMICOLON	U+003B

There can be either just one Parameter or any number of consecutive Parameters separated by semicolon. After the last Parameter, the semicolon may or may not be present. Properties can have their closing (exit) element counterparts. Property is applied from the point of declaration and is valid until occurence of it's exit element or up to the closest Structure Exit Tag or Section Markup Tag.
 
 

TemlCode Example

~<underline>This is ~<bold;italic>Some Text

 
Property Exit

Property Exit Markup Tags can be either in Short form or in Named form.

Short Form

Syntax of Short form of Property Exit Tag

~>

This short form closes nearby Property found by tracing back for the first unclosed Property. When found, it cancels out the validity of all it's Parameters and makes that starting Property closed, so another tracing back will skip this starting Property as already closed.
 
 

TemlCode Example

This part ~<bold;italic>is Bold and Italic,~> but this is not.

 
Named Form

Syntax of Named form of Property Exit Tag

~<~NameRef [ ";" ~NameRef ";" ... ";" ~NameRef ] >

This named form closes nearby Property found by tracing back for the first unclosed Property, which contains unclosed Parameters to which all NameRef(s) are referencing to. When found, it cancels out the validity of Parameters matched by NameRefs(s) and makes those Parameters closed, so another backtrace will skip those closed Parameters, while validity of Parameters unmatched by NameRef(s) is kept in active state.
 
 

TemlCode Example

This part ~<bold;italic>is Bold and Italic,~<~italic> and this is left just Bold.

 
Backtrace for appropriate Start Property Markup Tag stops at enclosing Structure Start Markup Tag or Section Markup Tag. This implicates, that Properties are local to the scope of individual Section or Structure blocks.
 
 

Remarks

The use of Tilde "~" character before NameRef reference resembles the destructor declaration in C++ programming language, and has the same semantics - to destroy something.

 
Parameter

Parameter defines a single element of property. It consist of name and optionally type and value.

Syntax of Parameter

Id | Var [ ":" Type ] [ "=" Entry ]

Character	Name	Code Point
:	COLON	U+003A
=	EQUALS SIGN	U+003D

The compulsory name of parameter can be either Identificator or Variable. Both categories live in their own name spaces, so there can be Identificator with same name as another Variable. TemlCode implementations should treat Identificators as once-create -> once-write & many-read, while Variables as once-create -> many-write & many-read.

Each parameter has some type. Type is explicitely defined by Type or inferred from the Entry value nature. When type is not defined and also not inferred, it is by default a Boolean True. In the examples above ~<underline>, ~<bold> and ~<italic> are all of type Boolean True.
 
 

TemlCode Example of full defined Property Parameters

~< A4_Page_Width : millimeters = 210; A4_Page_Height : centimeters = 29.7 >

 
There are types preddefined by TemlCode specification called CrossTypes. When Type name is not preddefined or declared, it's type nature is inferred from the Entry value nature. In example above the "millimeters" is type of integer nature and "centimeters" is type of real nature. If a value wouldn't be defined, it would be of boolean nature.

Id

Identificator names some functional aspect. It should be treated by implementation as once created and assigned, but many times readed property. If consequent property defines Id parameter of already defined name, implementation should create another instance of that property parameter. [*1]

Syntax of Identificator (Id)

( "_" | Letter ) & [ "_" | Letter | Digit ]*

Character	Name	Code Point
_	LOW LINE	U+005F
Letter
a .. z	LATIN SMALL LETTER A .. Z	U+0061 .. U+007A
A .. Z	LATIN CAPITAL LETTER A .. Z	U+0041 .. U+005A
Digit
0 .. 9	DIGIT ZERO .. DIGIT NINE	U+0030 .. U+0039

 

Note

From the broader view of point, this Id syntax is used as basic building block throughout the rest of this specification.

 
Var

Variable names some functional aspect. It should be treated by implementation as once created and many times changed and readed property. If consequent property defines Var parameter of already defined name, implementation should modify the content of that already existing Var property parameter. [*1]

Syntax of Variable (Var)

"#" & Id

Character	Name	Code Point
#	NUMBER SIGN	U+0023

 

TemlCode Example

~<font="Arial">This defined Identificator~> ~<#font="Times New Roman">This defined Variable~>

 
NameRef

We use name reference (NameRef) as a collective title for either Identificator (Id) or Variable (Var) for the purposes of this specification. This applies also to the above mentioned named form of Property Exit.

Type

The optional Type definition can explicitly specify the type class of property parameter. This is good for unique determination of what nature of data the property should contain. In some cases, the name of Type can just namely indicate some option, without being relevant to particular type class, respective the type class gets inferred from the nature of the entry value. For instance, in the above example with "millimeters" and "centimeters", these Type names have a little relativeness to basic data types because both can be of real or integer nature. So their actual data type is inferred from the entry value and the name itself gives just an indication, what conversion metrics should be used on appropriate property parameter value.

Types can be predefined CrossTypes, user declared types, inferred option types and inferred enumerated item types. All of them can be optionaly defined as single or multidimensional array, where size declares the maximum number of elements on a given dimension.

Syntax of Type
1.	CrossType	[ "[" Size [ ,Size ,... ,Size ] "]" ]
2.	&Id
3.	Id
4.	&Id(Id)

Character	Name	Code Point
,	COMMA	U+002C
&	AMPERSAND	U+0026

1. CrossTypes

Name	Alias	Range	Unit Size
Integer Types
int8		-128 .. 127	1 byte
int8u		0 .. 255	1 byte
int16		–32,768 .. 32,767	2 bytes
int16u		0 .. 65,535	2 bytes
int32	int	–2,147,483,648 .. 2,147,483,647	4 bytes
int32u	unsigned	0 .. 4,294,967,295	4 bytes
int64		-9,223,372,036,854,775,808 .. 9,223,372,036,854,775,807	8 bytes
int64u		0 .. 18,446,744,073,709,551,615	8 bytes
Real Types
single		1.5 x 10^–45 .. 3.4 x 10^38, 7–8 digits	4 bytes
double		5.0 x 10^–324 .. 1.7 x 10^308, 15–16 digits	8 bytes
currency		–922,337,203,685,477.5808 .. 922,337,203,685,477.5807, 19-20 digits	8 bytes
Character Types
char		0 .. 255	1 byte
wide		0 .. 65,535	2 bytes
full		–2,147,483,648 .. 2,147,483,647	4 bytes
String Types - RW
CharString		(0 .. 255) * int	1 byte
WideString		(0 .. 65,535) * int	2 bytes
FullString		(–2,147,483,648 .. 2,147,483,647) * int	4 bytes
String Types - Zero Terminated (Constant)
char_ptr		(0 .. 255) * int	1 byte
wide_ptr		(0 .. 65,535) * int	2 bytes
full_ptr		(–2,147,483,648 .. 2,147,483,647) * int	4 bytes
Boolean Types
bool8	bool	0 .. 255	1 byte
bool16		0 .. 65,535	2 bytes
bool32		0 .. 4,294,967,295	4 bytes

2. User Declared Types

Type previously declared in TemlCode. To visually discern types explicitly defined, an Ampersand "&" character immediately prefixes Id definition. The corresponding Entry value should be then defined according to it's previous type declaration.
 
 

TemlCode Example

~<birthday : &date = (day=14, month=3, year=1879 )>Albert Einstein~>

 
3. Inferred Option Types

Inferred Option Type is not previously declared type. It's name indicates some option for the processing application. Type itself is inferred from the nature of the Entry value. If Entry value is not defined, then the default inferred type is enumerated type with just one item of itself. This kind of types is good for quick definitions, which except the value itself, clearly state, what option is choosed at the same time for given property parameter.
 
 

TemlCode Example of Inferred Option Type definitions

~<text_color : gray> ~<price : eur = 499.50>

 
4. Inferred Enumerated Item Types

Similar to Inferred Option Type. It differs by name of Type, which should be previously declared as enumerated type. Id in parenthesis is one of defined enumeration items. This gives a possibility for processing application, to validate the Type definition against it's declaration. Type itself is inferred from the nature of the Entry value. If Entry value is not defined, then the inferred type is already declared enumerated type, with value of item defined.
 
 

TemlCode Example of Inferred Enumerated Item Type definition

~<price : &currency(usd) = 499.50>

 
Type Arrays

Any TemlCode property parameter can be memory sized by single or multiple dimensions. Array part comes after Type definition. Each array dimension is single integer number denoting particular dimension maximum of elements. To access that dimension an index from 0 to maximum - 1 can be used. Multiple dimensions are separated by comma ",".
 
 

TemlCode Example of Array Types

~<prices : eur[3] = [299, 399, 499]> ~{&coord=int32} ~<triangle : &coord[3,2] = [[100, 10], [200, 100], [10, 100]]>

 
Entry

The optional Entry definition can explicitly specify a value of the property parameter. Entry value should conform to it's Type definition if available. [*1] Entry value range from simple ordinal values like integers to a very complex multidimensional arrays with record type elements or casts.

Syntax of Entry

Value | Array | Record | Cast | Deref

Entry.Value

Direct value of some ordinal type.

Syntax of Entry.Value

Integer | Real | Boolean | Sequence | Id | Ref | Var

TemlCode Example of Entry.Values

1. ~<year = 2008> Integer value ~> 2. ~<full_opacity = 0xFF> Integer value in Hexadecimal format ~> 3. ~<pi = 3.14159265> Real value ~> 4. ~<bold> Implicit Boolean value of True ~> 5. ~<print_header = *> Explicit Boolean value of True ~> 6. ~<show_grid = !> Explicit Boolean value of False ~> 7. ~<font = "Arial"> String sequence, type char_ptr ~> 8. ~<#font = "Timpani"> String sequence, type CharString ~> 9. ~<#language = $65E5$672C$8A9F> WideString containing word "Japanese" () ~> 10. ~<tone = $1D11E$1D160> full_ptr with musical symbols () ~> 11. ~<color = Yellow> Enumerated Id value ~> 12. ~<style = css@mystyle> Reference value ~> 13. ~<file = #site_map> Variable value ~>

 
Entry.Value.Integer

Syntax of Entry.Value.Integer

1. [ "+" | "-" ] & Digit*

2. [ "+" | "-" ] & [ "0" & ~"x" & ( ~"a".."f" | Digit )* ]

Character	Name	Code Point
+	PLUS SIGN	U+002B
-	HYPHEN-MINUS	U+002D
0	DIGIT ZERO	U+0030
x	LATIN SMALL LETTER X	U+0078
X	LATIN CAPITAL LETTER X	U+0058
a .. f	LATIN SMALL LETTER A .. F	U+0061 .. U+0066
A .. F	LATIN CAPITAL LETTER A .. F	U+0041 .. U+0046

 
Entry.Value.Real

Syntax of Entry.Value.Real

[ "+" | "-" ] & Digit* & [ "." & Digit* & [ ~"e" & [ "+" | "-" ] & Digit* ] ]

Character	Name	Code Point
.	FULL STOP	U+002E
e	LATIN SMALL LETTER E	U+0065
E	LATIN CAPITAL LETTER E	U+0045

 
Entry.Value.Boolean

Remark the "*" and "!" notation for explicit booleans (5. & 6. above). We choosed this form, because keyword like True and False means in our TemlCode rules a definition of enumerated item. "!" character resembles the "not" meaning from C/C++ language and "*" character was one of a few by which no value definition starts, and thus it was free. The star "*" also resembles the ratings meaning, where more stars means better, so if just one star is there, then it exists (it's true).

Character	Name	Code Point
!	EXCLAMATION MARK	U+0021
*	ASTERISK	U+002A

 
Entry.Value.Sequence

TemlCode is focused on easiness of entering I18N text data. It is possible to enter international text by a hand without the need to have the underlying file in MBCS encoding. This is achieved by a syntax, where individual text code points can be entered in ascii as decimal (% prefix) or hexadecimal ($ prefix) values. In combination with classical ".." string syntax and by consequently serializing these strings (".."), hexadecimal ($hex) and decimal (%dec) elements and by concatenating pieces of such sequences with "+" character (in line or over line), any international text of any size can be entered by a hand.

Syntax of Entry.Value.Sequence

( ( String | (Hex) | (Dec) )* + [ "+" ] )*

String

" & [ "" | 0x20 | 0x21 | 0x23..0x10FFFF ]* & "

Hex

"$" & ( ~"a".."f" | Digit )*

Dec

"%" & Digit*

Character	Name	Code Point
%	PERCENT SIGN	U+0025
$	DOLLAR SIGN	U+0024
"	QUOTATION MARK	U+0022

TemlCode Example of Entry.Value.Sequences

~<question = "Do you speak " + $65E5%26412$8A9F + " ?"> Contains "Do you speak 日本誟 ?" phrase with the "japanese" word written in it's native language. ~> ~<message = "Jacket costs 20" + %8364 + " and trousers 35" + $20AC + "."> Message is "Jacket costs 20€ and trousers 35€." ~>

 
As can be seen here, particular blocks of string sequence are concatenated with "+" character. This allows for strings definitions overcrossing the boundaries if individual lines. TemlCode parser concatenates such sequence into the one continual string, and depending on of what maximum code point values it contains, provides the string data in CharString, WideString or FullString format type.

The blocks with either $hexadecimal or %decimal code point values can be written as an uninterrupted sequence without the need of "+" character concatenator. Note also, hexadecimal value of $20AC for "€" sign is the same as it's decimal value of %8364. Same applies to code point of %26412, which is equal to $672C in the word "japanese".

Entry.Value.Ref

Reference is TemlCode related data category. It is possible to individually label particular Markup Tag and then reference it with this type. Property parameters itself doesn't have the option to be labelled, but the Entry value part can contain such references. (Labelling of Markup Tags is described in Sections chapter.)

Syntax of Entry.Value.Ref

Id & "@" & Label

Label

( Name | StringFF ) & [ "." & ( Name | StringFF ) ]* & [ ":" & ( Name | StringFF ) ]

Name

( "_" | Letter | Digit ) & [ "_" | Letter | Digit ]*

StringFF

" & [ "" | 0x20 | 0x21 | 0x23..0xFF ]* & "

Character	Name	Code Point
@	COMMERCIAL AT	U+0040

TemlCode Example of Entry.Value.Refs

~<href = web@temlcode.overview:version023> ~<image = jpeg@"Architecture Diagram.jpg">

 
Entry.Array

Array definition can contain subarrays of any depth nesting. It should correspond to it's Type Array definition. If Type Array isn't defined, this data array definition assigns it's array layout to be it's property parameter memory structure.

Syntax of Entry.Array

"[" + Entries + "]"

Entries

Entry + [ "," + Entry ]*

Entry.Record

Record entry value definition allows for named or unnamed approach. With named approach, the order of data fields in it's data record type is not important, because parser is able to fill the data structure by matching it's field names. With unnamed approach, data fields must be entered exactly in the order of it's record type definition, but on the other side such definition takes up less space by ommiting the relevant field names.

Syntax of Entry.Record

"(" + [Declare] + ")"

Declare

[ Id + "=" ] + Entry + [ "," + [ Id + "=" ] + Entry ]*

TemlCode Example of Entry.Record

Types Declaration ~{&currencies = (usd; eur; jpy) } ~{&payment = (amount : double; currency : &currencies ) } Data Definition ~<price_1 : &payment = (currency = usd, amount = 299.50)> valid named approach, fields order is unimportant ~> ~<price_2 : &payment = (usd, 299.50)> invalid unnamed approach, wrong fields order ~> ~<price_3 : &payment = (299.50, usd)> valid unnamed approach, proper fields order ~>

 
Entry.Cast

Any of above mentioned Entry value definitions can be explicitly casted for the purposes of indication of what user meant the data to be for. If casting type is previously already declared type, the parser should align data into the memory layout of casting type. Otherwise, cast may serve as just informational indicator for the processing application about what to do with data.

Syntax of Entry.Cast

( "&" & Id ) & ( "(" + Entries + ")" )

TemlCode Example of Entry.Casts

Type Declaration ~{&rgba_color = (r : int8u; g : int8u; b : int8u; a : int8u) } Data Casts ~<#rgba_channels = &rgba_color(0xFFAA7733)> #rgba_channels.r = 0xFF, #rgba_channels.g = 0xAA, #rgba_channels.b = 0x77, #rgba_channels.a = 0x33. ~> ~<fill = &gradient(Red, Blue, Yellow)>

 
Entry.Deref

Entry value data definition can refer to some variable, whose content is to be assigned to a new property parameter. Dereference can be used on this variable data definition to access individual record or array fields, if the variable data type is of record type or an array. Record fields are accessed with full stop "." and name of field. Array elements are accessed through Indexes in square brackets separated by a comma ",". Indexes are numbered from 0 to Size - 1 on each dimension. Dereference accessors can nest to any depth according to the relevant data type declaration memory layout.

Syntax of Entry.Deref

"#" & Id & ( [ "[" + ( Index | Deref + [ "," + Index | Deref ]* ) + "]" ] & [ "." & Id ]* )

TemlCode Example of Entry.Derefs

~<item_price = #prices[10 ].unit_price>

 
Summary of TemlCode data definition syntax

This chapter specificated of how data elements can be defined in TemlCode property markup elements. Properties as a basic building blocks, are used for data definitions also in the rest of TemlCode markup tags. Following table summarizes the data definition syntax principles by which data types are being inferred, if not explicitly defined.

Syntax beginning	Inferred data type
+ - Digit	Integer or Real
0xDigit	Integer in hexadecimal notation
*	Boolean True
!	Boolean False
".."	String
$hex	Char type in hexadecimal notation
%dec	Char type in decimal notation
Id	Enumerated item
Id@Label	TemlCode specific reference
#Id	Variable reference

 

[*1]

This implementation behaviour is subject to user defined protocol.

 

Tell Us What You Think

Your Name
Your Email
Your Message	We accept anonymous messages. However, if you wish to receive a response, please include your email and name.

---

Next Chapter TemlCode Sections