Gang violence rampant in Hawke’s Bay
by New Zealand National PartyBrett Hudson - Police
20 November 2019
The Government’s soft on crime approach has led to Police taking matters into their own hands to address the problem of gang violence, National’s Police spokesperson Brett Hudson says.
“A special Gang Focus unit has been set up in Hawke's Bay to address the swelling instances of gang violence in the region.
“There were four gang-related attacks in 24 hours in Hawke’s Bay alone this week, including a violent standoff at the Napier Medical Centre.
“Gang membership has increased by 26 per cent in the past two years, and Hawke’s Bay has seen a 58 per cent increase.
“National proposed implementing Firearms Prohibition Orders that would have given police greater tools to get guns out of the hands of gangs. But the Government blocked this from becoming law over a year ago.
"As a result the Police Minister now has bigger problems with gangs and firearms in his own backyard and people across Napier and Hawkes Bay are at greater risk than they would have been.
“Gangs do nothing but peddle misery and create more victims. They are running rampant because this Government has no plan to keep New Zealander’s safe.
“National is committed to clamping down on gangs and keeping New Zealanders safe. Next week we will release our Law and Order Discussion Document which will highlight some of our ideas for addressing the growing gang problem in New Zealand.”
ends


What is Mathematics Series
The Natural Numbers
The natural numbers were created by the human mind out of the necessity to count the objects around us. Most basics of mathematics are associated with association of numbers with tangible objects. But advanced mathematics is built on top of the abstract concept of number system.
God created natural numbers; everything else is man’s handiwork.
Laws of Arithmetic
Natural numbers have only two basic operations, namely, addition and multiplication. The mathematical theory of the natural numbers or positive integers is known as arithmetic. Arithmetic is based on the fact that operations on numbers are governed by certain laws.
(a, b, c … symbolically denote integers)
The fundamental laws of arithmetic are:
- Commutative law, i.e. \(a+b = b+a\) and \(ab = ba\)
- Associative law, i.e. \(a + (b + c) = (a + b) + c\) and \(a(bc) = (ab)c\)
- Distributive law, i.e. \(a(b+c) = ab + ac\)
Addition and subtraction are inverse operations because, \((a+d)-d = a\). Similarly, multiplication and division are inverse because \({a \over d} \cdot d = a\). Also, 0 and 1 are the identities of operations addition and multiplication respectively.
Representation of Integers
A number system has a set of digit symbols and numbers where digit symbols are used to denote the larger numbers not available directly in the set of digit symbols. Modern number systems are associated with the place values of individual digits in the number, such as,
These are called positional notations. Here, a large number can also be represented using the basic symbols from the set of digit symbols. It is useful to have a way of indicating the result in a general form using a uniform logic, i.e. a general method for representing an integer, \(z\) in the decimal system is to express it as follows
which would be represented by the symbol \(a_na_{n-1}\cdots a_1a_0\)
Specifically, in case of decimal system the base is 10 as can be seen in the equations above. But, in general, for a number system any number greater than 1 can serve as the base of the system. E.g. a septimal system has base 7 and an integer is expressed as,
and it would be represented by the symbol \(b_nb_{n-1}\cdots b_1b_0\)
As a result 109 in decimal system is represented by 214 in septimal system for the reason shown below
As a general rule, in order to convert from base 10 to base B, perform successive divisions of number z by B; the remainders in reverse order would be the number representation in the system with base B.
Too small a base base has disadvantages (even a small number like 72 has a lengthy representation 1,001,111 in the dyadic system i.e. the binary system), while a large base requires learning many digit symbols, and an extended multiplication table.
The duodecimal system, i.e., choice of base 12 is advocated in many places, because it is exactly divisible by two, three, four, and six. Due to this property, works involving division and fraction are simplified.
Early systems of numerations were not positional in nature, but were based on purely additive principle. E.g. in roman symbolism,
i.e., the symbol \(CXVIII\) represents 118. Same was true about other early number systems like the Egyptian, Hebrew, Greek systems of numeration.
Disadvantage of any purely additive notation is that it requires more and more number of new symbols as the number to be represented gets larger. Also, the computation with additive systems is so difficult to perform, that computation was confined to a few adepts in the ancient times.
The positional system has the property that all numbers, however large or small, can be represented by the use of a small set of different digit symbols. Also, the major advantage lies in the ease of computation.
Computation in Other Number Systems
A very curious property of the decimal number system that points to usage of other number systems in the past is the number words used. E.g. the words for 11 and 12 are not constructed as the other teens are, suggesting a linguistic independence from words used for 10. Such peculiarities suggest remnants of use of other bases, notably 12 and 20.
Words vingt and quartevingt used for 20 and 80 respectively in French suggest a possibility of number with base 20. There are traces of Babylonian astronomers using a number system called sexagesimal (base 60).
The tables for addition and multiplication change with number system while the rules of arithmetic remain the same.
Below is the table for addition followed by table for multiplication in duodecimal number system. (10 and 11 in the duodecimal representation below are represented using A and B respectively.)
| + | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | 10 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | 10 | 11 |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | 10 | 11 | 12 |
| 4 | 5 | 6 | 7 | 8 | 9 | A | B | 10 | 11 | 12 | 13 |
| 5 | 6 | 7 | 8 | 9 | A | B | 10 | 11 | 12 | 13 | 14 |
| 6 | 7 | 8 | 9 | A | B | 10 | 11 | 12 | 13 | 14 | 15 |
| 7 | 8 | 9 | A | B | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 8 | 9 | A | B | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 9 | A | B | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| A | B | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| B | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 1A |
| . | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B |
| 2 | 2 | 4 | 6 | 8 | A | 10 | 12 | 14 | 16 | 18 | 1A |
| 3 | 3 | 6 | 9 | 10 | 13 | 16 | 19 | 20 | 23 | 26 | 29 |
| 4 | 4 | 8 | 10 | 14 | 18 | 20 | 24 | 28 | 30 | 34 | 38 |
| 5 | 5 | A | 13 | 18 | 21 | 26 | 2B | 34 | 39 | 42 | 47 |
| 6 | 6 | 10 | 16 | 20 | 26 | 30 | 36 | 40 | 46 | 50 | 56 |
| 7 | 7 | 12 | 19 | 24 | 2B | 36 | 41 | 48 | 53 | 5A | 65 |
| 8 | 8 | 14 | 20 | 28 | 34 | 40 | 48 | 54 | 60 | 68 | 74 |
| 9 | 9 | 16 | 23 | 30 | 39 | 46 | 53 | 60 | 69 | 76 | 83 |
| A | A | 18 | 26 | 34 | 42 | 50 | 5A | 68 | 76 | 84 | 92 |
| B | B | 1A | 29 | 38 | 47 | 56 | 65 | 74 | 83 | 92 | 101 |
REFERENCES:
What is Mathematics? Second Edition - Chapter I: Natural Numbers


Edit your Analysis settings, invite and manage participants, and draft an email message.
Step 1
These are the details others will see for this Data & Tech Analysis.
Step 2
These are the individuals who will be invited to participate.
Step 3
Each participant will receive an email invitation. You can customize the email message here.
Step 4
Learning Questions help your team focus on key aspects of your district's data and technology implementation.


{% extends 'base.html' %} {% block body_block %}
Simon is a a senior lecturer in the School of Computing Science
at the University of Glasgow.
His research interest involves the development of Machine Learning and Statistical techniques to
help with the analysis of complex datasets, particularly within the field of Metabolomics but also
other -omics fields, Human-Computer Interaction and Information Retrieval.
His metabolomics work is done in collaboration with many people, particularly
Glasgow Polyomics (of which he's an affiliate member).
After his PhD in Wageningen, The Netherlands, Justin moved to Glasgow Polyomics to
work with Dr Karl Burgess and Prof. Mike Barrett and different partners from Glasgow Polyomics. Justin obtained an ISSF Fellowship from the Wellcome Trust to work on
method development and implementation of fragmentation approaches to enhance the metabolite annotation capacities of the high-resolution LC-MS systems focusing on small
polar metabolites in urine, beer, and bacterial extracts. Justin has been working on several metabolomics projects thereby exploiting the information-rich fragmentation
data that modern mass spectrometers generate and alleviate the bottleneck of metabolite annotation and identification in untargeted metabolomics approaches. In the MS2LDA
project, Justin provides valuable biological data interpretations and insights that is crucial to the development of the system. He recently moved back to his academic roots
to take up a shared Postdoc position between WUR and the group of Prof. Pieter Dorrestein at the UCSD, USA. The work will be focusing on how to combine workflows developed
for genome and metabolome mining to aid in functional annotations of genes and structural annotations of metabolites.
Joe is a data scientist
at Glasgow Polyomics, University of Glasgow. Before working at Glasgow Polyomics, Joe was a PhD student at the School of Computing Science, supervised by Simon.
His research interest is in natural language processing and the application of machine learning methods to the analysis of complex biological data.
In particular, this also involves the necessary large-scale processing of data required prior to modelling and also the effective visualisations of analysis results.
The following people have contributed codes, patches and new features to this project, and we would like to acknowledge their massive contributions. Without their help, this project would not be where it is now.


 Save with AIG Car Hire Excess Insurance!
|
|
|
We've all done it haven't we. Arrived in an airport and had to pay double thanks to car hire excess or extras. It's hardly the perfect start to your holiday? So here's a way to start your holiday relaxed. |
|
|
|
|
Relax with AIG Car Hire Excess Insurance!
AIG's Car Hire Excess provides a reimbursement of the excess applied to your car rental agreement that is both value for money and offers you the best possible coverage. You also get a full range of benefits such as cover from less than 14 cent per day, Free Personal Accident coverage up to €40,000 as standard, coverage for fire, theft and vandalism and much more...
AIG have got your travel insurance in the bag no matter what's on the itinerary. Single Trip, Annual Multi-Trip, Long Stay / Backpacker and Family, ensure you get the best type of cover for your individual needs. This will depend on the type of travel you are about to undertake. See our travel insurance options here to decide what cover you should be looking for and ensure you are fully prepared to have that relaxing holiday. See how much you can save! |
|
|
|
|
|
|


Toggle navigation
Home
Calendar
Genome Data
Profile
Data Uploads
Sign Out
Calendar.
Record your menstrual cycle.
Record


Download App Id Log In Pics. You then securely log in with face id, touch id, or a passcode. App id verifies that the entity that makes the request is authorized and returns access an access token to your app.
Select app ids and hit continue. Your apple id is the account you use for all apple services. I have a premium trial but on the windows 10 desktop app there is no sign in with apple id option but there is one on the web app.
If this error persists, contact your account owner to check your permissions.
Here enter any description and a bundle id. You'll need to integrate the app id into your app's source code to use certain features in admob.  Log in to your apple developer account.


diferente
User-friendly virtual DOM diffing
Open up the console and you'll notice only the text node is getting updated.
Get it on GitHub!
bevacqua/diferente


Home
-
Schemas
#STATUSMESSAGE#
Your schemas
Schema
Power
Number of devices
Execution Time
Days
Has conditions
#SCHEMAS#
With selected:


A row within an IDL.
The client may access the following attributes directly:
- 'uuid': a uuid.UUID object whose value is the row's database UUID.
- An attribute for each column in the Row's table, named for the column,
whose values are as returned by Datum.to_python() for the column's type.
If some error occurs (e.g. the database server's idea of the column is
different from the IDL's idea), then the attribute values is the
"default" value return by Datum.default() for the column's type. (It is
important to know this because the default value may violate constraints
for the column's type, e.g. the default integer value is 0 even if column
contraints require the column's value to be positive.)
When a transaction is active, column attributes may also be assigned new
values. Committing the transaction will then cause the new value to be
stored into the database.
*NOTE*: In the current implementation, the value of a column is a *copy*
of the value in the database. This means that modifying its value
directly will have no useful effect. For example, the following:
row.mycolumn["a"] = "b" # don't do this
will not change anything in the database, even after commit. To modify
the column, instead assign the modified column value back to the column:
d = row.mycolumn
d["a"] = "b"
row.mycolumn = d
| def ovs.db.idl.Row.verify |
( |
|
self, |
|
|
|
column_name |
|
) |
| |
Causes the original contents of column 'column_name' in this row to
be verified as a prerequisite to completing the transaction. That is,
if 'column_name' changed in this row (or if this row was deleted)
between the time that the IDL originally read its contents and the time
that the transaction commits, then the transaction aborts and
Transaction.commit() returns Transaction.TRY_AGAIN.
The intention is that, to ensure that no transaction commits based on
dirty reads, an application should call Row.verify() on each data item
read as part of a read-modify-write operation.
In some cases Row.verify() reduces to a no-op, because the current
value of the column is already known:
- If this row is a row created by the current transaction (returned
by Transaction.insert()).
- If the column has already been modified within the current
transaction.
Because of the latter property, always call Row.verify() *before*
modifying the column, for a given read-modify-write.
A transaction must be in progress.
613 def verify(self, column_name):
614 """Causes the original contents of column 'column_name' in this row to
615 be verified as a prerequisite to completing the transaction. That is,
616 if 'column_name' changed in this row (or if this row was deleted)
617 between the time that the IDL originally read its contents and the time
618 that the transaction commits, then the transaction aborts and
619 Transaction.commit() returns Transaction.TRY_AGAIN.
621 The intention is that, to ensure that no transaction commits based on
622 dirty reads, an application should call Row.verify() on each data item
623 read as part of a read-modify-write operation.
625 In some cases Row.verify() reduces to a no-op, because the current
626 value of the column is already known:
628 - If this row is a row created by the current transaction (returned
629 by Transaction.insert()).
631 - If the column has already been modified within the current
634 Because of the latter property, always call Row.verify() *before*
635 modifying the column, for a given read-modify-write.
637 A transaction must be in progress."""
639 assert self._changes
is not None
640 if not self._data
or column_name
in self._changes:
643 self._prereqs[column_name] =
None


{% block title %}
Photos by {{ flickr_user.name }}
{% endblock %}
{% include 'flickr/includes/user.html' with user=flickr_user account=account perms=perms only %}
{% include 'flickr/includes/annual_photo_counts.html' with user=flickr_user only %}
{% include 'flickr/includes/nav_tabs.html' with user=flickr_user active='photos' only %}
{% include 'flickr/includes/sorting.html' with request=request order=order only %}
{% include 'flickr/includes/photo_columns.html' with request=request photo_list=photo_list order=order page_obj=page_obj perms=perms only %}


This page is used to control what smileys are supported by the wiki. Just write the text of a smiley to display it.
- :)
- :-)
- :D
- :-D
- B)
- B-)
- :))
- :-))
- ;)
- ;-)
- :\
- :-\
- :/
- :-/
- :|
- :-|
- >:>
- X-(
- <:(
- :(
- :-(
- :-?
- :-P
- :o
- |)
- |-)
- {OK}
- {X}
- {i}
- (./)
- (!)
- [!]
- /!\
- (?)
- {x}
- {*}
- {o}
- {1}
- {2}
- {3}
For example:
To change the supported smileys, just edit the lists on this page. Note that the format is important; each list item should start with the text that is turned into the smiley, escaped so that users can see what produces it, followed by a WikiLink to the image to display.
Bear in mind that the link to the image needs to be written in a way that will work if it's copied to other pages on the wiki. So be sure to include the smileys directory in the path to the file.


Format and Length Preserving Encryption¶
Format and Length Preserving Encryption (FLPE) are ways of encrypting data while keeping the cipher text format or size the same as the input. For example, with format preserving encryption, a credit card number will still look like a credit card number after encrypting, and will still pass the Luhn check required. With length preserving encryption, the cipher text will have the same size as the plain text. These approaches comes with security implications that must be understood.
On key rotation¶
FLPE requires that the output be the same format or length as the input, which means that no information about the key can be stored with the cipher text. Additionally, the premise for FLPE is that the storage container cannot be changed, so key information cannot be stored alongside the cipher text. This means that once a key is selected for encryption, that same key needs to be used for all data. For the SDK, that means using a non-rotatable Smartkey.
Non-rotatable Smartkeys have serious drawbacks. When a user with access to a non-rotatable Smartkey has their access revoked, Smartcrypt deletes the key from the user’s devices, same as with rotatable Smartkeys. However, the key could have been compromised. With rotatable Smartkeys we issue a new encryption key for use in all future encryptions, thereby ensuring that the removed user cannot access new data; with non-rotatable Smartkeys we continue to use the same encryption key.


Temperature
°C
Today Tips
A wonderful serenity has taken possession of my entire soul, like these sweet mornings of spring which I enjoy with my whole heart.Bandwidth Usage
Mbps
Outcome
75%
HDD Usage
132Gb Free Space
1,45Gb Used space
Earning
$764 Today
$1,332 Last 7 Day
Sales
$764 Today
$1,332 Last 7 Day
Task Progress
34 Completed
79 Total
Progress
| Invoice | User | Order date | Amount | Status | Tracking Number |
|---|---|---|---|---|---|
| Order #53431 | Steve N. Horton | Oct 22, 2014 | $45.00 |
Paid
|
- |
| Order #53432 | Charles S Boyle | Oct 24, 2014 | $245.30 |
Shipped
|
CGX0089734531 |
| Order #53433 | Lucy Doe | Oct 24, 2014 | $38.00 |
Shipped
|
CGX0089934571 |
| Order #53434 | Teresa L. Doe | Oct 15, 2014 | $77.99 |
Shipped
|
CGX0089734574 |
| Order #53435 | Teresa L. Doe | Oct 12, 2014 | $18.00 |
Paid
|
- |
| Order #53437 | Charles S Boyle | Oct 17, 2014 | $658.00 |
Refunded
|
- |
| Order #536584 | Scott S. Calabrese | Oct 19, 2014 | $45.58 |
Unpaid
|
- |


In the previous two sections we looked at the basics of how to create a replicated environment, and what exceptions you can expect to see in a JE HA application. Now we need to combine these two topics in order to examine how you should open a ReplicatedEnvironment handle to an existing replicated environment.
When you open the handle, the underlying HA code will attempt to open a TCP/IP connection to other nodes in the replication group, based on the node's stored replication group metadata or the helper host information that you provide. In doing so, the node will attempt to locate a Master or, failing that, will hold an election in order to select a new Master, if it is an electable node.
Due to issues of timing and network performance, the node may or may not be able to:
locate the master; and
hold an election.
This can happen if there simply are not enough electable nodes available in order for the current node to start up, find the current master, or hold an election. Remember that a majority of the electable nodes registered in the replication group must be available in order to hold an election.
If this situation occurs, the ReplicatedEnvironment constructor will throw an UnknownMasterException. Therefore, typically, it is best that you prepare for this situation by performing the handle creation in a retry loop, as shown in the following code snippet.
In addition, if the Replica has been down for a long enough period of time, it might be so far out of date that it cannot be brought up to date using the normal replication stream. In this case, the ReplicatedEnvironment constructor will throw an InsufficientLogException. See Restoring Log Files for information on how to handle this exception.
private static int REP_HANDLE_RETRY_MAX = 100; ... ReplicatedEnvironment getEnvironment(File envHome, String groupName, String nodeName, String nodeHost, String helperHosts) throws IllegalStateException, InterruptedException { EnvironmentConfig envConfig = new EnvironmentConfig(); envConfig.setAllowCreate(true); envConfig.setTransactional(true); // Identify the node ReplicationConfig repConfig = new ReplicationConfig(); repConfig.setGroupName(groupName); repConfig.setNodeName(nodeName); repConfig.setNodeHostPort(nodeHost); repConfig.setHelperHosts(helperHosts); for (int i = 0; i < REP_HANDLE_RETRY_MAX; i++) { try { return new ReplicatedEnvironment(envHome, repConfig, envConfig); } catch (UnknownMasterException ume) { /* * Insert application specific code here to indicate that * this problem was encountered, such as writing the * condition to a log file. */ Thread.sleep(5 * 1000); continue; } catch (InsufficientLogException ile) { /* A network restore is required, make the necessary calls */ } } throw new IllegalStateException("getEnvironment: reached max retries"); }
Note that for production code, you may want to retry the handle open without any maximum retry limit.


My DBC Projects
Pair Programming
Check it out!
Cheat Sheets
SQL
Ruby vs JavaScript Loops
Git
Next Project
holder
holder
holder


Recipe and special effect
Note: Before trying this homework, you should perform an update as described: here
- We will start by creating a recipe for a special sword
- We will give it a custom name
- We will check to see if it is inhand when the player clicks
- Extra Credit: Create a kill-aura effect when it is in hand and clicked
Starting recipe
Here is an example starting recipe, you can use your imagination to change the ingredients
After you have created this recipe, download the code, /reload, /js test() and confirm that the code behaves the way you expect
You should be able to craft the item at a crafting table
Add a custom name
From Items, Stack, insert the Set name to: Custom Name between Result Stack and Stack of 1, then change the Custom Name to "Destroyer" or some other name of your choosing
Note: You must have the double quotes for the code to work properly.
After you have inserted this, download the code, /reload, /js test() and check the behavior.
When you craft the item the custom name should appear when it is in your hand
Add a player click check
From World, Events, Add a Listener Event below the recipe and change the event to Player Mouse Click
From Scriptcraft Coding, Variables, add a Set Name =, and change name to player
From World, Events, connect an Event Information to the Set player =
Change the Event Information from all affected entities to: player
From Scriptcraft Coding, Variables, add a Set Name =, and change name to inhand
From Items, Stack, Connect the Custom Name of Stack to the Set inhand =
From Entities, Player, Connect the Stack in hand of Player to the Custom name of Stack
From Scriptcraft Coding, Variables, connect variable:name to the Stack in hand of Player
From Output place a SendMessage inside the listener Event, below the Set inhand = block
Change the message from "Hello" to "Inhand: " + inhand
From Scriptcraft Coding, Variables, connect a variable:name to the SendMessage and change name to player
Download the code, /reload, /js test() and check the behavior.
When you have the special sword in hand and click the mouse you should get the message: "Inhand: " and then the custom name of the Sword
You can use this diagram for reference: AOTE


@since Oak 1.0.18, 1.2.3
Lucene indexing is performed in a single threaded mode. Extracting text from binaries is an expensive operation and slows down the indexing rate considerably. For incremental indexing this mostly works fine but if performing a reindex or creating the index for the first time after migration then it increases the indexing time considerably. To speed up such cases Oak supports pre extracting text from binaries to avoid extracting text at indexing time. This feature consist of 2 broad steps
For more details on this feature refer to OAK-2892
Oak run tool provides a tika command which supports traversing the repository and then extracting text from the binary properties.
Download following jars
Refer to oak-run setup for details about connecting to different types of NodeStore. Example below assume a setup consisting of SegmentNodeStore and FileDataStore. Depending on setup use the appropriate connection options.
You can use current oak-run version to perform text extraction for older Oak setups i.e. its fine to use oak-run from 1.7.x branch to connect to Oak repositories from version 1.0.x or later. The oak-run tooling connects to the repository in read only mode and hence safe to use with older version.
The generated extracted text dir can then be used with older setup.
Of the following steps #2 i.e. generation of csv file scans the whole repository. Hence this step should be run when system is not in active use. Step #3 only requires access to BlobStore and hence can be run while Oak application is in use.
As the first step you would need to generate a csv file which would contain details about the binary property. This file would be generated by using the tika command from oak-run. In this step oak-run would connect to repository in read only mode.
To generate the csv file use the --generate action
java -jar oak-run.jar tika \ --fds-path /path/to/datastore \ /path/to/segmentstore --data-file oak-binary-stats.csv --generate
If connecting to S3 this command can take long time because checking binary id currently triggers download of the actual binary content which we do not require. To speed up here we can use the Fake DataStore support of oak-run
java -jar oak-run.jar tika \ --fake-ds-path=temp \ /path/to/segmentstore --data-file oak-binary-stats.csv --generate
This would generate a csv file with content like below
43844ed22d640a114134e5a25550244e8836c00c#28705,28705,"application/octet-stream",,"/content/activities/jcr:content/folderThumbnail/jcr:content" 43844ed22d640a114134e5a25550244e8836c00c#28705,28705,"application/octet-stream",,"/content/snowboarding/jcr:content/folderThumbnail/jcr:content" ...
By default it scans whole repository. If you need to restrict it to look up under certain path then specify the path via --path option.
Once the csv file is generated we need to perform the text extraction. To do that we would need to download the tika-app jar from Tika downloads. You should be able to use 1.15 version with Oak 1.7.4 jar.
To perform the text extraction use the --extract action
java -cp oak-run.jar:tika-app-1.15.jar \ org.apache.jackrabbit.oak.run.Main tika \ --data-file binary-stats.csv \ --store-path ./store \ --fds-path /path/to/datastore extract
This command does not require access to NodeStore and only requires access to the BlobStore. So configure the BlobStore which is in use like FileDataStore or S3DataStore. Above command would do text extraction using multiple threads and store the extracted text in directory specified by --store-path.
Currently extracted text files are stored as files per blob in a format which is same one used with FileDataStore In addition to that it creates 2 files
This phase is incremental i.e. if run multiple times and same --store-path is specified then it would avoid extracting text from previously processed binaries.
Further the extract phase only needs access to BlobStore and does not require access to NodeStore. So this can be run from a different machine (possibly more powerful to allow use of multiple cores) to speed up text extraction. One can also split the csv into multiple chunks and process them on different machines and then merge the stores later. Just ensure that at merge time blobs*.txt files are also merged
Note that we need to launch the command with -cp instead of -jar as we need to include classes outside of oak-run jar like tika-app. Also ensure that oak-run comes before in classpath. This is required due to some old classes being packaged in tika-app
In this step we would configure Oak to make use of the pre extracted text for the indexing. Depending on how indexing is being performed you would configure the PreExtractedTextProvider either in OSGi or in oak-run index command
@since Oak 1.0.18, 1.2.3
For this look for OSGi config for Apache Jackrabbit Oak DataStore PreExtractedTextProvider
Once PreExtractedTextProvider is configured then upon reindexing Lucene indexer would make use of it to check if text needs to be extracted or not. Check TextExtractionStatsMBean for various statistics around text extraction and also to validate if PreExtractedTextProvider is being used.
Configure the directory storing pre extracted text via --pre-extracted-text-dir option in index command. See oak run indexing


Get Started
Understand The System
The first step of achieving a realistic Modo model is to analyze and understand the system to be modeled as realistically as possible. It is not a time consuming effort to remodel the system using Modo. However a more realistic analysis will save you time to focus on the solution in deeper details.
For the quick-start example, let's think of the registration system of a university.
Define Main Elements
The registration system most likely has students, instructors and courses. Those can be considered as the main elements of that system, and below is how you represent them.
/* Registration System Element Declarations */
Student;
Instructor;
Course;
As seen above the elements of a system can be declared that easily. However when you want to add the properties of those elements, it is better to use the below representation.
/* Registration System Element Declarations */
Student{
}
Instructor{
}
Course{
}
It is the common practice to define singular elements, and let the frameworks handle the groups of those elements. That is why the above example defines Student, Instructor and Course, instead of Students, Instructors and Courses.
Define Member Elements
The elements of the registration system have some properties in real-life. Like the name and surname of a student, like the ID of a course etc. Those properties are called member elements in Modo.
/* Registration System Element Declarations */
Student {
Name = String;
Surname = String;
ID = Number;
GPA = Number;
}
Instructor {
Name = String;
Surname = String;
ID = Number;
}
Course {
Name = String;
ID = Number;
Instructor = Instructor;
}
As you can see in the example above the member elements are defined within the curly brackets of the related element. The equal sign (=) is used to assign the types of the member elements. The types of the member elements can be built-in elements or other elements that are previously defined by the user. The later enables the easy modeling of the relations between elements.
Modo language does not contain any built-in elements. However, built-in elements can be defined in different syntaxes of Modo, which are designed for different technologies.
In lines 3, 4, 9, 10 and 14 the built-in element String is used, where in line 18 the user-defined element Instructor is used as the type of the member element.
Element Type vs. Element Value
When there is a need to access the value of a certain member element, a dollar symbol ($) is placed preceding the element name.
/* Student Element Declaration */
Student {
Name = String;
Surname = String;
ID = Number;
GPA = Number;
Fullname = String;
$Fullname = $Name + ' ' + $Surname;
}
In the above example the type of the Fullname member element is String. However the value of the element is a string combination of the values of the member elements Name and Surname. This shows that at any time, the value of the fullname property of a student is his/her name, surname and a single space in between them.
Extend Your Elements
Different elements can be derived from built-in elements or previously defined elements.
/* Registration System Element Declarations */
Student {
Name = String;
Surname = String;
ID = Number;
GPA = Number;
Advisor = Advisor;
}
Instructor {
Name = String;
Surname = String;
ID = Number;
}
Advisor = Instructor {
OfficeDay = Weekday;
}
In the above example a new element Advisor is defined. The advisor is in fact an Instructor but an additional property of office day is added.
The member elements can also be extended like the elements.
/* Registration System Element Declarations */
Student {
Name = String;
Surname = String;
ID = Number;
GPA = Number;
Advisor = Instructor {
OfficeDay = Weekday;
}
}
Instructor {
Name = String;
Surname = String;
ID = Number;
}
In the above example the member element Advisor of the element Student extends the element Instructor adding the property of office day.
Different States of the System
Modo can also represent different states of the system. The at symbol (@) is used to define those rules.
/* Registration System Element Declarations */
Student {
Name = String;
Surname = String;
ID = Number;
GPA = Number;
CanGraduate = Boolean;
$CanGraduate = true @ ($GPA >= 2);
$CanGraduate = false @ ($GPA < 2);
}
The above example adds a new member element CanGraduate to the Student element. The value of this member element changes for different values of the GPA member element.
For more detailed information, please download Modo Language Specification Document.
Motivation
Information technologies provide solutions to make our lives easier. Some of them have little effect on our daily and profesional lives, where some can completely change them. Even further, internet makes these solutions, time and location free.
This rapidly changing world of IT, emerges the need of robust, flexible and efficient software development methods and paradigms. These methods and paradigms should be easy to use, implement and integrate. In addition, these methods and paradigms should have the ability to adapt to the rapidly changing needs and technologies. Numerous studies have been made and several methods have been proposed. Today, these methods are being used by many of the professioanls of the IT and related fields.
However the complex nature of the current methods requires technical knowledge in depth. This technical depth widens the gap between IT and the non-IT professionals.
Moreover, with the increasing shift of systems to the online world, there still resides a need to have a semantic representation tool to model and convert real life systems to the world of computers.
In order to address the above issues and more, we propose the Modo language.
What is Modo?
Modo is an easy-to-use modeling language which is used for modeling systems, their subsystems, super systems (the system that encompasses the system that is in focus) and environment. The simple syntax of Modo allows easy modeling for not only the IT professionals but also for the professionals from non-IT fields. The well-structured and machine-readable nature of Modo also allows direct conversion of the models to different programming languages and technologies, thus serving as a technology independent modeling method.
Brief History
A significant part of software development can be described as an effort of modeling real-life systems, using the computer systems. Computer systems, which are more static, have structured (explicitly definite) or semi-structured nature. On the other hand real-life systems, which are more dynamic, can be structured, semi-structured or most of the time, unstructured.
In the year 2005, a concept for software development was proposed by Aykut Aydınlı to be used for the projects of Sanpark. The main idea of this concept was to isolate the analysis and the design of real-life systems from the boundaries of computer systems. With the help of this isolated analysis, the idle effort of modeling an unstructured real-life system into a computer system is avoided and the resulting computer system serves as a complete solution. Ensuring the computer system is designed for the real-life system; not vice-versa.
The isolated analysis needs a method to model and define the real-life system. First real-life system definition was made using XML in the late 2005. This definition enabled isolated analysis of real-life systems, automated conversion to existing technologies, and initiated real-life system versioning. This first definition syntax was used by Sanpark for two years.
In late 2007, after observing the short-comings of the previous syntax a new language, which does not use the XML syntax anymore, has been constructed for system definition and semantic representation. And there the Modo language was born. There were two main reasons for abandoning the XML syntax:
- XML syntax is not easily readable/writable for non-IT professionals and
- XML is not sufficient to declare systems' different conditions, modes and states for different time frames and/or conditions.
Modo's latest shape was given and the language specification was finalized by Aykut Aydınlı and Doruk Eker in June, 2009.
The Name Modo
The word "modo" means "mode" in Esperanto language. Esperanto language is a constructed (artificial) language. It is constructed to narrow the gap between people speaking different languages, having different cultures and having different beliefs.
Similarly Modo language is constructed to narrow the gap between people from different disciplines, different technical expertise and different viewpoints.
The Zero Defect Software
From a certain point of view, a software which is not serving the needs of the user can be considered as defected. This can be caused by one or both reasons listed below:
- There are coding errors (bugs) within the code of the software.
- The real-life system/problem related to the software was poorly or never analyzed, therefore the resulting computer system fails to serve the real-life system.
One should overcome the above issues to get closer to the zero-defect software phenomenon.
The first type of errors are the runtime errors, namely the bugs in the software. At every line of code developed, there is a certain probability of having something wrong. Therefore as the number of lines of code developed for a project/software increases, the probability of having an error also increases. Reducing the number of lines of code developed specifically for a software project reduces the number of errors. Code generators enable the reduction in number of lines of code. Once the initial bugs in the generator are fixed, in unit time the generated code becomes bug-free.
Modo is designed to be well-structured and machine readable, and therefore it is possible to use generators to convert Modo models to different languages. With the help of this feature Modo addresses the runtime errors.
The second type of errors is the design-time errors which are basically the errors that occur when analyzing the systems. The quality of the system analysis is directly related with the experience of the analyzer. However, even for the inexperienced analyzer, the design-time errors can be fixed with trial and error. The trial and error method can only be efficient if the time needed for each trial is affordable. The simple syntax of Modo combined with the rapid code generation, decreases the time needed to try different scenarios. Therefore enabling the trial and error process and addressing also the design-time errors.
Semantic Web and Modo
Every moment information technologies yield a large amount of information waiting for humans and systems to discover, filter, process and generate. As the amount of information increases, we have drastically less time to discover, filter and process this information. For this reason, no matter how precise and accurate a piece of information is, it starts to become meaningless, unless its meaning and relations can be understood and processed automatically by computers. Adding the meaning to any piece of information at its very source is the key solution for this problem. This ensures that the information is in the same format at any point of the system, hence the effort of all semantic web standards and specifications.
A system which is modeled using Modo, is automatically represented at the semantic level. Different Modo models can include the required metadata for every piece of information to be delivered. This approach of Modo is aimed to be a contribution for the ongoing search of a common semantic definition method.
Term of Use
This website provides information about the Modo language that is developed by Sanpark. Sanpark may partially or entirely update the content of this website at any time and without prior notice.
Modo language site content is licensed under a Creative Commons Attribution 3.0 License.
Introduction
By reducing the time and cost of the solutions of real life problems, information technologies had a deep impact on the every little aspect of both our professional and daily lives. Especially with the urge of the internet era, this impact is drastically increasing as the solutions now became time-free and location-free (Park and Lim, 1999; Calvary et al., 2003; Rau et al., 2004; Lam and Swayne, 2001; Kim 2001).
One of the largest challenges of the IT field is the gap between the real world systems and their representations in the computer, or to be more specific today's online world. Numerous professionals proposed notations, languages and methods to provide solutions to narrow this gap (Kernighan and Ritchie, 1978; Wirth, 1971; Gosling et al., 2005; Tom, 2001; Booch et al., 2000; Heng and Mackie, 2009; Laporti et al., 2009; Horsburgh et al., 2009; Reinhartz-Berger and Sturm, 2009 ; Schwabe and Rossi, 1998). Most of those solutions are being used by many of the IT and related professionals today.
However, with the increasing shift of systems to the online world there still resides a need to have a representation tool to model and convert real life systems to the world of computers.
Considering the online world of today and the predicted integrated and semantic, structure of tomorrow, one can easily say that this new tool
- should allow faster modeling,
- should be easy to use,
- should be able to represent every element of the real life systems,
- should be able to represent the relations between the elements of the real life systems,
- should easily be used for modeling different systems,
- should be able to produce a representation which can be interpreted not only by humans but also by machines,
- should be able to produce a representation which can easily be converted to the existing or the future technologies.
Considering the above reasons and more, we propose the Modo language.
About the document
This document contains the specification of the Modo language. In this first chapter, Introduction, the acknowledgement and the general information about the document is mentioned.
The rest of the document contains the following chapters:
Motivation chapter covers the underlying reasons, which led us to develop Modo.
Definitions chapter covers the technical terminology and jargon that we find compulsory to make the most use of this document.
Structure and Syntax chapter gives detailed information about the syntax of the language using Extended Backus-Naur Form, Extended BNF (ISO/IEC 14977, 1996). Along with the syntax, lexical sequence, constraints and rules are also described.
Elements chapter covers the element declarations and the uses of the elements in Modo definitions.
Selectors chapter introduces selectors conceptually. Additionally selector syntax and the uses of the selectors are described in this chapter.
Expressions chapter gives information about the expressions for operators, constants, strings and elements.
Scope
This document specifies/contains structure and syntax of the Modo language.
This document does not specify/contain
- use cases
- system dependent elements/methods
- technology dependent elements/methods
- conversions and interpretations of Modo to other technologies
Conformance
This document is intended for developers, designers, system designers and modelers and other related professionals whose activities contain modeling of real life systems for computer technologies.
For better understanding of this document, the audience must have experience in the following:
- Object oriented system modeling
- Computer programming languages
- EBNF notation (ISO/IEC 14977, 1996)
Credits And Acknowlegement
The authors thank Sanpark IT & Design Co. Ltd., for maintaining the professional environment and encouragement that resulted and catalyzed the development of Modo. They also thank Recep Kütük from Sanpark for the Modo identity and the document formatting.
Modo language is shaped by the ideas, practice and experience of Aykut Aydınlı and the Sanpark crew; starting from 2005. The latest version of Modo is shaped by Aykut Aydınlı and Doruk Eker.
This document is authored and edited by Aykut Aydınlı and Doruk Eker.
Motivation
The basic idea that initiated the effort for the development of Modo was to create a modeling tool, which is able to model a real life system, its elements and the relations between them.
Modo focuses on the system to be modeled, as it exists. The technological boundaries and constraints, which are only obstacles of the computer systems, are neglected during the modeling process. The model then can be converted to the required technologies. This conversion can be designed to catalyze any software development process, reducing the cycle time of development/maintenance and increasing the quality of the software.
Moreover, Modo is aimed to be a contribution for the ongoing studies for the Semantic Web, which is considered to be the next era of online information delivery (Berners-Lee et al., 2001). Modo models represent entities of real life systems and the relations between them. Thus the system is modeled at the semantic level, and more importantly this model is completely machine-readable. With the help of this property, Modo can act as a common definition language at semantic level and help different systems (online/offline) to be integrated.
All those properties of the language led us to show the effort to develop Modo.
Definition
This document contains technical details about Modo language. These technical details necessitate the use of technical terminology. This chapter gives the definitions of some of these technical terms for making the most use of this document.
- System is the real life system that is modeled using Modo.
- Element is the single member of a system.
- Member Element is the sub element of an element.
- Modo Generator/Compiler/Interpreter is the application that can compile and convert the Modo declarations into different technologies or formats.
- Syntax is a piece of code that is sequenced together to form a meaningful Modo sentences.
- Grammar is the set of rules that are used to code Modo declarations.
Structure And Syntax
This chapter describes the basic structure of the Modo language. Additionally Modo syntax is introduced in this chapter.
Syntax
This section defines the Modo syntax. Besides some fundamental differences, Modo syntax shows similarities to Cascading Style Sheets (CSS) language specified in Bos et al. (Bos et al., 2009). The reasons for these similarities are 1) CSS provides great ease for the definition of the elements and their properties and 2) common use of CSS language among different disciplines, especially designers and developers.
Modo syntax is defined using Extended BNF metalanguage specified in ISO/IEC 14977 (ISO/IEC 14977, 1996). By using the Extended BNF metalanguage, syntactic sequence of the Modo is separated into lexical units. This helps to identify every lexical unit in a meaningful Modo sentence.
These definitions include some of the main syntactic parts of the Modo language. For the complete list of definitions, please refer to Appendix A. Grammar.
Following example shows the declaration of an element in Modo syntax:
/* Company Element Declaration */
Company {
Name = String;
$Name = "Doe Software Inc.";
Founder = String;
$Founder = "John Doe";
TaxNumber = String;
$TaxNumber = "123456789987654321";
}
The example above shows the declaration of Company element. On line 1, a descriptive comment is added to the declaration. On line 2, the declaration of the Company element starts.
On lines 3, 5 and 7 the member elements, Name, Founder and TaxNumber of the Company element are declared respectively. On lines 4, 6 and 8 initial values of those member elements are assigned. Please note that the dollar symbol "$" preceding the member element name refers to the value of that member element.
Finally on line 9, Company element declaration ends with end declaration symbol "}".
Note: The above example assumes that the element String has already been defined.
Tokenization
For better understanding, Modo syntax is separated into tokens at lexical level. A Modo declaration consists of a sequence of these tokens.
Following is the general Extended BNF notation of the Modo:
modo = {
directive | rule | declaration | comment
};
As you can see above, Modo definition consists of directives, rules, declarations and comments. Followings are the Extended BNF notations of each token:
(* Directive Definition *)
directive = {blank}, at symbol, identifier,
{blank}-, expression, {blank},
end sentence symbol;
(* Rule Definition *)
rule = {blank}, at symbol, {blank},
start group symbol, {blank},
expression, {blank}, end group symbol,
{blank}, start declaration symbol,
{blank}, modo, {blank},
end declaration symbol;
(* Comment Definition *)
comment = delimited comment
| single line comment;
(* Declaration Definition *)
declaration = {
assignment
| basic declaration
| extended declaration
};
Characters (The Unicode Standard, 2003), letters, numerals, symbols and operators used in Modo syntax are defined as follows:
letter = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H"
| "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P"
| "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X"
| "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f"
| "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n"
| "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v"
| "w" | "x" | "y" | "z";
character = any Unicode character;
whitespace = {
space character
| tab character
| line feed character
| carriage return character
| form feed character
};
new line = carriage return character
| line feed character
| next line character
| line separator character
| paragraph separator character;
space character = " ";
tab character =
? The Unicode Standard Tab Character (U+0009) ? ;
line feed character =
? The Unicode Standard Line Feed Character (U+000A) ? ;
carriage return character =
? The Unicode Standard
Carriage Return Character (U+000D) ? ;
form feed character =
? The Unicode Standard Form Feed Character (U+000C) ? ;
next line character =
? The Unicode Standard Next Line Character (U+0085) ? ;
line separator character =
? The Unicode Standard
Line Separator Character (U+2028) ? ;
paragraph separator character =
? The Unicode Standard
Paragraph Separator Character (U+2029) ? ;
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7"
| "8" | "9";
at symbol = "@";
assignment symbol = "=";
end sentence symbol = ";";
start group symbol = "(";
end group symbol = ")";
start declaration symbol = "{";
end declaration symbol = "}";
backslash symbol = "\";
start attribute selector symbol = "[";
end attribute selector symbol = "]";
start delimited comment symbol = "/*";
end delimited comment symbol = "*/";
start single line comment symbol = "//";
dot symbol = ".";
comma symbol = ",";
underscore symbol = "_";
hyphens symbol = "-";
escaped single quote symbol = "\'";
escaped double quote symbol = '\"';
single quote symbol = "'";
double quote symbol = '"';
increment operator = "++";
decrement operator = "--";
unary operator = "+" | "-" | "!" | "~"
| increment operator
| decrement operator;
operator = "*" | "/" | "%" | "+" | "-" | "<<" | ">>" | "<"
| ">" | "<=" | ">=" | "==" | "!=" | "&" | "^" | "|"
| "&&" | "||";
unary selector operator = "$", ".", "#", "?", " ";
selector operator = ">", "<", "+", "-", "~", "^", ":",
"::", "%", "&", "|", "\", "/";
selector expression operator = "*" | "/" | "%" | "+" | "-"
| "<<" | ">>" | "<" | ">" | "=" | "&" | "^" | "|"
| "<=" | ">=" | "==" | "!=" | "*=" | "/=" | "%="
| "+=" | "-=" | "&=" | "^=" | "|=" | "$=" | "~="
| ".=" | "#=" | "?=" | ":=" | "&&" | "||";
universal selector = "*";
Additionally there are some extra tokens used in Modo syntax. For the sake of continuity, only main syntactic parts are shown here. Please refer to Appendix A. Grammar for complete list of tokens.
In Modo syntax, characters of any kind including whitespace are not allowed between syntactic parts.
Only the space character, tab character, line feed character, carriage return character and form feed character can occur in whitespace
Characters and case
Modo syntax is case-insensitive. Elements and member elements declared in Modo can be considered as case-insensitive.
Following is the Extended BNF notation of identifier and lhs identifier:
identifier = {letter | underscore symbol}-,
{
digit
| letter
| underscore symbol
};
The identifier definition above shows that the identifier starts with letter or underscore symbol "_" and can continue with digit, letter or underscore symbol "_".
lhs identifier = {
letter
| underscore symbol
| hyphens symbol
}-,
{
digit
| letter
| underscore symbol
| hyphens symbol
};
The left-hand side selector (lhs) identifier shows that lhs identifier starts with either letter, underscore symbol "_" or hyphens symbol "-".
/* Company Element Declaration */
Company {
Name = String;
$Name = "Doe\'s Software Inc.";
Founder = String;
$Founder = "John Doe";
TaxNumber = String;
$TaxNumber = "123456789987654321";
}
The example above shows the declaration of Company element. In this declaration Company, Name, Founder and TaxNumber are the left-hand side identifiers.
Additionally, there is an alternative use of backslash symbol "\" in strings. Backslash symbol is used to print single and double quote symbols in string values. Also for printing backslash symbol in string values, one must specify two backslash symbols "\\" consecutively.
Following is the Extended BNF notation of escaped single quote symbol and escaped double quote symbol:
escaped single quote symbol = "\'";
escaped double quote symbol = '\"';
In addition to that, string, single quote escaped string and double quote escaped string definitions are as follows:
string = (
single quote symbol,
single quote escaped string,
single quote symbol
)
|
(
double quote symbol,
double quote escaped string,
double quote symbol
);
single quote escaped string = {
(any Unicode character - single quote symbol)
| escaped single quote symbol
};
double quote escaped string = {
(any Unicode character - double quote symbol)
| escaped double quote symbol
};
Directives
Directives are the instructions directly related with the Modo generators/compilers/interpreters. They are not a part of the system declared in Modo. Directives start with at symbol "@" and continue with identifier and expression. Finally, directives end with end sentence symbol ";".
(* Directive Definition *)
directive = {blank},
at symbol,
identifier,
{blank}-,
expression,
{blank},
end sentence symbol;
Rules
In Modo syntax, Rules play an important role of representing the different states of a system. In real life, the elements of a system might contain different properties or values for different states of the system. When modeling the system, those different states, values and properties must be included in the model. In Modo syntax, those different properties and values are reflected using the Rules.
Declarations, types and the values of the elements can be specified depending on rules. With the help of rules, values and properties of the system can be changed or set depending on one or more conditions. Rules start with at symbol "@".
There are two types of rules: 1) Rule blocks and 2) inline rules. Following is the Extended BNF notation of rules (rule blocks) and inline rules:
rule = {blank},
at symbol,
{blank},
start group symbol,
{blank},
expression,
{blank},
end group symbol,
{blank},
start declaration symbol,
{blank},
modo,
{blank},
end declaration symbol;
The rule definition above shows that rule starts with at symbol "@", and continues with start group symbol, expression and end group symbol. After rule expression is specified, rule specific declaration starts with start declaration symbol. Any meaningful Modo declaration can be placed between declaration symbols. Finally, rule ends with end declaration symbol.
inline rule = {blank},
at symbol,
{blank},
start group symbol,
{blank},
expression,
{blank},
end group symbol;
Similarly, the inline rule starts with at symbol "@" and continues with start group symbol, expression and end group symbol.
Following example shows the use of rules in Modo declarations:
Company {
Name = String;
$Name = "Doe Software Inc.";
$Name = "DOE Corp." @ ($CurrentYear > 2008);
Founder = String;
$Founder = "John Doe";
TaxNumber = String;
$TaxNumber = "123456789987654321";
}
The example above shows the use of inline rules. On line 2, the Name member element of the Company element is defined and on line 3, it is assigned an initial value. On line 4, another value is assigned to the Name element, but this time depending on the rule ($CurrentYear > 2008).
Imagine a scenario where the company's name was changed to "DOE Corp." in the year 2008. Therefore, once the value of the CurrentYear is greater than 2008 the value of the Name element is "DOE Corp.". In other cases, the value of the Name element is "Doe Software Co.,Ltd.".
Company {
Name = String;
Founder = String;
TaxNumber = String;
$Name = "Doe Software Inc.";
@ ($CurrentYear > 2008) {
$Name = "DOE Corp.";
}
$Founder = "John Doe";
$TaxNumber = "123456789987654321";
}
The example above shows the use of rule blocks. On line 6, rule block starts with at symbol "@". On line 7, a new value is assigned to the Name element. Finally, rule block ends with end declaration symbol on line 8.
One possible implementation of Rules in Modo syntax is to define a value or property of elements that does not change in any state of the system.
For the previous scenario, assume that the tax number of the company is always the same. Therefore, value of the TaxNumber element never changes. The following example shows the Modo syntax, which defines an everlasting rule.
Company {
Name = String;
Founder = String;
TaxNumber = String;
$Name = "Doe Software Inc.";
$Founder = "John Doe";
$TaxNumber = "123456789987654321" @ (1);
}
In the above example, the elements are defined similarly to the previous example. However, when assigning values a rule is defined for the value of the TaxNumber element. On line 7, after the value is assigned to the TaxNumber element the rule (1) is defined. This rule indicates that, for all states of the system the value of the TaxNumber element is "123456789987654321".
Note: The above examples assume that the member element CurrentYear and element String have already been declared.
Blocks
Blocks are used for element and rule declarations. In Modo syntax, blocks start with start declaration symbol "{" and end with end declaration symbol "}" ( Appendix A. Grammar). Every start declaration symbol must end with end declaration symbol.
Similarly, in string values if a string starts with single quote symbol, it must end with single quote symbol. In addition, if a string starts with double quote symbol, it must end with double quote symbol. Every expression that starts with start group symbol "(" likewise ends with end group symbol ")".
Selectors
Modo syntax provides some pattern-matching rules for element and member element declarations. These pattern-matching rules are called "Selectors".
Modo syntax introduces selectors conceptually. For further information, please refer to Selectors.
Elements
Elements are the basic Modo structures that define real life entities. Elements can be declared by single line definitions or block declarations.
Following example shows the declaration of Company element.
/* Company Element Declaration */
Company {
Name = String;
$Name = "Doe Software Inc.";
Founder = String;
$Founder = "John Doe";
TaxNumber = String;
$TaxNumber = "123456789987654321";
}
Elements can be declared by extending built-in or previously declared elements. Following example shows the declaration of Worker and Developer elements:
Worker {
FirstName = String;
LastName = String;
Department = String;
}
The example above shows the declaration of Worker element. On line 1, "Worker" identifier is specified and declaration of the Worker element starts with start declaration symbol. On line 2, FirstName member element is defined. On line 3, LastName member element is defined and on line 4, Department member element is defined. Finally, element declaration ends with end declaration symbol.
Below is the declaration of the Developer element, which is an extension of the Worker element.
Developer = Worker {
$Department = "Software Development";
}
The example above extends the Worker declaration. On line 1, Developer element is declared extending the Worker element. Additionally on line 2, a specific value is assigned to the Department element.
Declarations
There are three types of Modo element declarations:
- Assignments
- Basic Declarations
- Extended Declarations
Assignments are one-line declarations where the assignment symbol "=" is used and values are assigned to the elements and member elements.
Basic declarations are the typical element declarations as blocks.
Extended declarations are the declarations that extend built-in or previously declared elements.
For further information about declarations, please refer to Declarations.
Expressions
Modo syntax allows using expressions for assignments. Following example shows the use of expression in assignments:
Worker {
$FirstName = "John";
$LastName = "Doe";
$FullName = ($FirstName + " " + $LastName);
}
The example above shows the declaration of Worker element. On line 4, the value of the FullName member element is specified by an expression. According to this expression, value of the FullName member element is composed of the value of the FirstName member element, the space character " " and the value of the LastName member element.
Modo declarations specify the state of the system for the given time periods. This nature of the Modo necessitates that the assignments must be valid for the given time periods. Therefore, for the above example, when the FirstName attribute value changes, FullName attribute value must be recalculated and updated by the generators/compilers/interpreters using this Modo model.
For further information, please refer to Expressions chapter.
Comments
There are two types of comments:
- Delimited Comments
- Single Line Comments
comment = delimited comment
| single line comment;
Delimited comments start with start delimited comment symbol "/*" and end with end delimited comment symbol "*/".
delimited comment = {blank},
start delimited comment symbol,
({character} - end delimited comment symbol),
end delimited comment symbol;
Single line comments start with start single line comment symbol "//" and end with any kind of new line character.
single line comment = {blank},
start single line comment symbol,
({character} - new line),
new line;
Comments include descriptions and notes about Modo declarations. Modo generators/compilers/interpreters ignore comments during generation, compiling and interpreting process. Comments are useful for making code more readable.
/* Beginning of Company element declaration */
Company {
/* Name member element definition */
Name = String;
/* Value assigned to Name element */
$Name = "Doe Software Inc.";
/* Founder member element definition */
Founder = String;
/* Value assigned to Founder element */
$Founder = "John Doe";
/* TaxNumber member element definition */
TaxNumber = String;
/* Value assigned to TaxNumber element */
$TaxNumber = "123456789987654321";
}
/* End of Company element declaration */
In the example above, comments are used on lines 1, 3, 5, 7, 9, 11, 13 and 16.
Values
There are two types of values in Modo syntax.
- Numeric values (integers and real numbers)
- Strings
All the element or member element values must be specified using either numeric values or strings.
Integers and real numbers
Integers and real numbers are formed by bringing digits [0-9] together.
Following is the Extended BNF notation of integer and constant (real number) syntax:
integer = "0" | (digit - "0", {digit});
constant = integer,
[
dot symbol,
{digit}-
];
The syntax above shows that constant (real number) values include integer values. Decimal digits are separated using dot symbol ".".
Strings
Except numerals, all the values in Modo declarations must be specified as strings. Strings start with single quote symbol or double quote symbol and end with single quote symbol or double quote symbol respectively. Following examples show the different use of strings:
A = "This is double quote string.";
A = 'This is single quote string.';
A = "This is double quote \" escaped string";
A = 'This is single quote \' escaped string';
A = 'This is a \'string\'';
A = "This is a \"string\"";
Elements
Modo is used for describing systems. For better understanding, the system, its subsystems, its super system (the system that encompasses the system that is in focus), its environment and context can be separated into meaningful pieces. This approach has different names for different disciplines (e.g. Systems approach, object-oriented design). This approach is handy for analyzing and modeling systems. Sharing the same point of view, Modo offers separation of systems into signicifant unique pieces for modeling. These pieces are called "Elements" in Modo syntax. This chapter gives information about the declaration and usage of elements in Modo syntax.
Declerations
Declarations are used for representing the real-life system entities as Modo elements. There are three types of declarations:
- Assignments
- Basic Declarations
- Extended declarations
Following sections give detailed information about declarations.
Assignments
Real-Life entities can have properties and sub elements. In Modo, these properties and sub elements are called "Member Elements".
Declaration of the elements can be made by assigning values to the member elements. In the following example assignments are used to declare the Company element.
Company Name = String;
Company Founder = String;
Company TaxNumber = String;
Company $Name = "Doe Software Inc.";
Company $Founder = "John Doe";
Company $TaxNumber = "123456789987654321";
The example above shows the declaration of Company element. On line 1, Name attribute is defined and on line 4 the value "Doe Software Co.,Ltd." is assigned. On line 2, Founder attribute is defined and on line 5, the value "John Doe" is assigned. Finally, on line 3, TaxNumber attribute is defined and on line 6, the value "123456789987654321" is assigned.
Extended Declerations
Element declarations can be made by extending built-in or previously defined elements. The extended element carries all the properties of the parent element. Additionally, extended element can have its original member elements.
Following are the basic declarations of the Worker element and the Developer element which extends the Worker element:
Worker {
Name = String;
Surname = String;
Department = String;
}
The above example is the basic declaration of the Worker element. On line 1, the declaration of the element starts. On lines 2, 3 and 4, the member elements Name, Surname and Department are defined respectively.
Developer = Worker {
$Department = "Software Development";
Expertise = String;
}
On line 1, Developer element is declared extending the Worker element. With this assignment, extended declaration of the Developer element starts. On line 2, a value, "Software Development", is assigned to the Department element. In the above example the Department element belongs to the Worker element. So in line 2, the Developer element extends the Worker element via assigning a value to an existing member element. However in line 3, a new member element Expertise, which belongs only to Developer element, is defined. So this time, the Worker element is extended via defining a new member element.
Using Elements
Declaration process of the Modo elements is not limited to specifying the member elements, but it also includes relating them with each other and other Modo elements. This section gives details about using elements.
Member Elements
In Modo syntax, all the properties/attributes of an element are also elements, which are called member elements. Member element declaration starting without any preceding characters, defines the type of the member element. The type of the member elements can be a built-in or previously declared element.
When the definition of the member element starts with the dollar symbol "$", this assignment specifies the initial value of this element in the system. If the initial value is assigned with a rule, then that value will be condition dependent.
Following is the Modo declaration of the Company element:
Company {
Name = String;
$Name = "Doe Software Inc.";
$Name = "DOE Corp." @ ($CurrentYear > 2008);
Founder = String;
$Founder = "John Doe";
TaxNumber = String;
$TaxNumber = "123456789987654321";
}
In the above example, on lines 2, 5 and 7, the member elements Name, Founder and TaxNumber are declared respectively. Their types are also specified as String, which is another built-in or previously declared element. On lines, 3, 6 and 8 initial values are assigned with the help of dollar symbol "$". On line 4, a different value is assigned to the Name member element, but this time depending on a rule ($CurrentYear > 2008).
Modo syntax also allows nested declarations where the member elements can extend an existing element. This nested declaration is one of the ways to define the relationship between the elements.
Following examples shows the nested declaration of member elements:
Worker {
Name = String;
Surname = String;
Department = String;
}
The example above shows the declaration of the Worker element. On lines 2, 3 and 4, the member elements Name, Surname and Department are declared respectively.
Department {
DepartmentName = String;
Manager = Worker{
$Department = $DepartmentName;
}
}
The above example shows the declaration of the Department element. On line 2, DepartmentName member element is declared. On line 3, member element Manager is declared extending the element Worker. On line 4, the value of the Department member element of the Manager element is assigned to the value of the DepartmentName member element.
Accessing Member Elements
The value of built-in elements, previously declared elements or member elements could be used while declaring the member elements.
Following examples give details about accessing member elements:
Worker {
FirstName = String;
LastName = String;
FullName = String;
$FullName = ($FirstName + " " + $LastName);
}
The example above shows the declaration of Worker element. On line 5, the value of the FullName member element is assigned using an expression that accesses the values of the FirstName and LastName member elements of the Worker element.
Worker {
$FirstName = "";
$LastName = "";
$FullName = ($FirstName + " " + $LastName);
}
Department {
DepartmentName = String;
Manager = Worker{
Title = String;
$Title = "Manager " + $FullName;
}
}
Above is an example of accessing element attributes in extended declaration. On line 11, Title attribute is assigned a value using an expression which accesses FullName attribute of the Worker element.
Functions and Member Methods
Modo syntax does not allow the definition of user defined functions and member methods. However, Modo generators/compilers/interpreters can provide some built-in functions and member methods.
This section gives information about using built-in functions and member methods in Modo declarations.
Following example shows the use of member methods in Modo declarations:
Worker {
FirstName = String;
LastName = String;
FullName = String;
$FullName = ($FirstName + " " + $LastName);
/* FormatCurrency function takes 2 parameters
* param1: Amount
* param2: Decimal Count
*/
Salary = String;
$Salary = FormatCurrency(1500, 2);
}
The example above shows the use of member methods in Modo declarations. On line 12, the value of the Salary member element is specified by the return value of FormatCurrency function. FormatCurrency function takes two parameters:
- Currency amount and
- Decimal count
The value of the Salary member element becomes "1500.00".
Warning: FormatCurrency function used in the example above only shows the use of member methods. This function is not a part of Modo syntax.
Note: The above examples assume that the element String has already been declared.
Selectors
Selectors provide control over elements. Selectors can define the scope of the declaration.
This chapter gives information about the uses of selectors over elements.
Selector Syntax
There are two types of selectors:
- Left-hand side selectors
- Right-hand side selectors
Following is the Extended BNF notation of left-hand and right-hand side selectors:
lhs selector = (
{blank},
universal selector | selector operand,
{blank},
{
selector operator,
{blank},
selector operand
}
),
{
{blank},
comma symbol,
{blank},
lhs selector
};
Left-hand side selectors have more complex structure than right-hand side selectors. The Extended BNF notation above shows that lhs selector consists of a selector operand or a universal selector, and a selector operator. Additionally, it is possible to specify more than one lhs selector by separating with comma symbol ",".
rhs selector = {blank},
[unary selector operator],
identifier,
{rhs selector};
The Extended BNF notation above shows that rhs selector consists of optional unary selector operator and an identifier. In addition to that, it is possible to specify more than one rhs selector.
Universial Selector
In Modo selector syntax, "*" symbol plays an important role. This symbol is called universal selector and used to match any single element. As specified in Appendix A. Grammar, universal selector can only be used in left-hand side selectors. The main reason for this convention is, right-hand side selectors are not allowed to address more than one element.
Grouping
Modo syntax provides grouping for left-hand side selectors. Left-hand side selectors may specify more than one element at a time. This is useful for declaring identical elements.
Warning: Grouping can only be used on left-hand side selectors. Right-hand side selectors have no grouping support.
Following example shows the use of grouping:
Developer, Designer = Worker {
FirstName = String;
LastName = String;
}
The example above shows the use of grouping. Both Developer and Designer elements are of type the Worker element. These elements are separated with comma symbol.
Selector Operators
There are two types of selector operators:
- Unary selector operators
- Binary selector operators
This section gives information about the use of these selector operators.
Unary selector operators
Unary selector operators are the selector operators that take one selector operand.
Following is the Extended BNF notation of the unary selector operators:
unary selector operator = "$", ".", "#", "?", " ";
Following examples shows the use of unary selector operators:
.Developer { }
#Developer { }
?Developer { }
Developer $Name = "";
Warning: The meaning and the use of these selector operators may be interpreted differently by different Modo generators/compilers/interpreters.
Binary Selector Operators
Binary selector operators are the selector operators that take two selector operands.
Following is the Extended BNF notation of the binary selector operators:
selector operator = ">", "<", "+", "-", "~", "^", ":",
"::", "%", "&", "|", "\", "/";
Following examples shows the use of binary selector operators:
Developer > $Name = "";
Developer < $Name = "";
Developer + Designer { }
Developer - Designer { }
Developer ~ Designer { }
Developer ^ Designer { }
Developer % Designer { }
Developer & Designer { }
Developer | Designer { }
Developer / Designer { }
Warning: The meaning and the use of these selector operators may be interpreted differently by different Modo generators/compilers/interpreters.
Selector Operands
Selector operands are the components of the selection operation affected by binary and unary selector operators.
Following is the Extended BNF notation of selector operand in Modo syntax:
selector operand = {blank},
[
[unary selector operator],
lhs identifier
],
{blank},
[
(
start group symbol,
[
selector expression,
{
{blank},
comma symbol,
{blank},
selector expression
}
],
{blank},
end group symbol
)
|
(
start attribute selector symbol,
selector expression,
{
{blank},
comma symbol,
{blank},
selector expression
},
{blank},
end attribute selector symbol
)
],
{selector operand};
The notation above shows that selector operands start with optional unary selector operator and lhs identifier. It is possible to specify a selector start with either start group symbol "(" or start attribute selector symbol "[". If a selector starts with start group symbol, it must end with end group symbol. Similarly, if a selector starts with start attribute selector symbol, it must end with end attribute selector symbol.
Selector Expressions
By the help of the selector operand expressions, not only the elements but also its member elements, member element values and member methods can be used in the left-hand side selectors.
Following is the Extended BNF notation of selector expression in Modo syntax:
selector expression = {blank},
{start group symbol},
{blank},
operand | expression,
{
{blank},
selector expression operator,
{blank},
{start group symbol},
{blank},
operand | expression,
{blank},
{end group symbol},
},
{blank},
{end group symbol};
The selector expression notation above shows that selector expression and expression notation have several tokens in common except the selector expression operator.
Following is the Extended BNF notation of selector expression operator:
selector expression operator = "*" | "/" | "%" | "+" | "-"
| "<<" | ">>" | "<" | ">" | "=" | "&" | "^" | "|"
| "<=" | ">=" | "==" | "!=" | "*=" | "/=" | "%="
| "+=" | "-=" | "&=" | "^=" | "|=" | "$=" | "~="
| ".=" | "#=" | "?=" | ":=" | "&&" | "||";
Expressions
An expression can be defined as a sequence of operands and operators (ECMA-334, 2006). In Modo syntax, expressions are used for the definition of elements and member elements.
Following is the Extended BNF notation of the expression in Modo syntax:
expression = {blank},
{start group symbol},
{blank},
operand | expression,
{
{blank},
operator,
{blank},
{start group symbol},
{blank},
operand | expression,
{blank},
{end group symbol},
},
{blank},
{end group symbol};
The expression definition above shows that expressions start with optional start group symbol, "(". An operand or expression follows this symbol. Then optional operator and operand/expression follow. Finally expression syntax ends with optional end group symbol, ")".
Operators
As mentioned in expression syntax, expressions are composed of operands and operators. Operators specify the operations that will be applied to the operands (ECMA-334, 2006).
In Modo syntax, there are two types of operators:
- Unary operators take one operand (e.g. -A, A++).
- Binary operators take two operands (e.g. A + B).
Following is the Extended BNF notation of unary operator and operator (Binary operator) in Modo syntax:
unary operator = "+" | "-" | "!" | "~"
| increment operator
| decrement operator;
operator = "*" | "/" | "%" | "+" | "-" | "<<" | ">>" | "<"
| ">" | "<=" | ">=" | "==" | "!=" | "&" | "^" | "|"
| "&&" | "||";
Expressions are evaluated from left to right. Operator precedence is the key factor that determines which operations will be applied to which operands.
Following table lists the precedence of the operators:
| Operator Precedence | ||
|---|---|---|
| Category | Operators | |
| 1 | Unary operators | + - ! ~ ++ -- |
| 2 | Multiplication operators | * / % |
| 3 | Addition operators | + - |
| 4 | Shifting operators | << >> |
| 5 | Relational operators | < > <= => |
| 6 | Equality operators | == != |
| 7 | Logical AND operator | & |
| 8 | Logical XOR operator | ^ |
| 9 | Logical OR operator | | |
| 10 | Conditional AND operator | && |
| 11 | Conditional OR operator | || |
First column specifies the priority of the operator. Unary operators have the highest priority (1) and conditional OR operator has the lowest (11) one. Second column specifies the category of the operator. Finally, third column lists the operators.
Unary Operators
Unary operators have the highest priority. These operators consist of:
- Unary plus operator is used to form an operation like +A. This operation results simply the value of the operand.
- Unary minus operator is used to form an operation like -A. This operation results the multiplication of the operand by (-1).
- Negation operator is used to form an operation like !A. This operation results the logical negative value of the operand.
- Bitwise complement operator is used to form an operation like ~A. This operation results the complement of the operand.
- Increment and decrement operators is used to form an operation like ++A, --A, A++ or A--. Increment operator (++A or A++) increases the operand value by one. Similarly decrement operator (--A or A--) decreases the operand value by one. Evaluating expressions from left to right can yield different results for ++A and A++. One must remember that, the operation ++A is calculated before the A++ operation.
Multiplication Operators
Multiplication operators have second highest priority. Multiplication operators consist of:
- Multiplication operator is used to form an operation like A * B. This operation results the multiplication of the operand A by B.
- Division operator is used to form an operation like A / B. This operation results the division of the operand A by B.
- Remainder operator is used to form an operation like A % B. This operation results the remainder of the division of the operand A by B.
Addition Operators
Addition operators consist of:
- Addition operator is used to form an operation like A + B. This operation results the addition of the operands A and B.
- Subtraction operator is used to form an operation like A - B. This operation results the subtraction of the operand B from A.
Shifting Operators
"<<" and ">>" symbols are used for bit shifting operations. Shifting operators consists of:
- Left-shifting operator is used to form an operation like A << 5. The A << 5 operation yields the 5 bits left-shifted value of the operand A.
- Right-shifting operator is used to form an operation like A >> 5. The A >> 5 operation yields the 5 bits right-shifted value of the operand A.
Relational Operators
"<", ">", "<=" ve ">=" symbols are used for relational operations. Relational operators consist of:
- "Less than" operator is used to form an operation like A < B. If the value of the operand A, is less than the value of the operand B, A < B operation yields the logical true value. If the value of the operand A, is greater than or equal to the value of the operand B, A < B operation yields the logical false value.
- "Greater than" operator is used to form an operation like A > B. If the value of the operand A, is greater than the value of the operand B, A > B operation yields the logical true value. If the value of the operand A, is less than or equal to the value of the operand B, A > B operation yields the logical false value.
- "Less than or equal to" operator is used to form an operation like A <= B. If the value of the operand A, is less than or equal to the value of the operand B, A <= B operation yields the logical true value. If the value of the operand A is greater than the value of the operand B, A <= B operation yields the logical false value.
- "Greater than or equal to" operator is used to form an operation like A >= B. If the value of the operand A is greater than or equal to the value of the operand B, A >= B operation yields the logical true value. If the value of the operand A is less than the value of the operand B, A >= B operation yields the logical false value.
Equality Operators
"==" and "!=" operators are used for equality operations. Equality operators consists of:
- "Equal to" operator is used to form an operation like A == B. If the value of the operand A is equal to the value of the operand B, A == B operation yields the logical true value.
- "Not equal to" operator is used to form an operation like A != B. The A != B operation is logically negative to the operation A == B. If the value of he operand A is not equal to the value of the operand B, A != B operation yields the logical true value.
Logical AND Operator
Logical AND operator is used to form an operation like A & B. This operation results the bitwise logical AND of the operands A and B.
Logical XOR Operator
Logical XOR operator is used to form an operation like A ^ B. This operation results the bitwise logical exclusive OR of the operands A and B.
Logical OR operator
Logical OR operator is used to form an operation like A | B. This operation results the bitwise logical OR of the operands A and B.
Conditional AND operator
Conditional AND operator is used to form an operation like A && B. This operation results the coditional AND of the operands A and B.
Conditional OR operator
Conditional OR operator is used to form an operation like A || B. This operation results the conditional OR of the operands A and B.
Constants and strings
Constant numeric values and strings can be used as operands in expressions.
Following is the Extended BNF notation of constant and string in Modo syntax:
constant = integer,
[
dot symbol,
{digit}-
];
The constant definition above shows that only the numeric values are considered as constants. A constant can be integer or real number. Decimal part of the number starts with dot symbol ".". Just like integer and real number which are numeric constants, string is the alphanumeric constant.
string = (
single quote symbol,
single quote escaped string,
single quote symbol
)
|
(
double quote symbol,
double quote escaped string,
double quote symbol
);
The string definition above shows that strings can start with single quote symbol ' or double quote symbol ".
Warning: If a string starts with single quote symbol, it must end with single quote symbol. In addition, if a string starts with double quote symbol, it must end with double quote symbol.
Elements and member elements
Elements and member elements can be considered as operands in Modo expressions.
For further information about elements and member elements, please refer to Using elements.
Functions and member methods
Unlike C, C++, C#, Java etc., function and/or method definition is not allowed in Modo syntax. Modo represents and forms the system and its states for the given time periods and for the given set of rules. Nevertheless, there can be built-in elements, functions and member methods defined in Modo language references specific for certain generators/compilers/interpreters. These built-in elements, functions and member methods can also be considered as operands in Modo expressions.
Appendix A. Grammer
(**
* MODO LANGUAGE DEFINITION
* -------------------------
* This chapter defines Modo language syntax using
* Extended BNF metalanguage.
* There are three parts in this definition:
* (1) Letters, characters, digits, symbols and operators
* (2) Identifier, expression and other lexical units
* (3) Final Modo definition
*
*)
(**
* MODO LANGUAGE DEFINITION Part I
* --------------------------------
* Letters, characters, digits, symbols and operators
*)
letter = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H"
| "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P"
| "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X"
| "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f"
| "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n"
| "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v"
| "w" | "x" | "y" | "z";
character = any Unicode character;
whitespace = {
space character
| tab character
| line feed character
| carriage return character
| form feed character
};
new line = carriage return character
| line feed character
| next line character
| line separator character
| paragraph separator character;
space character = " ";
tab character =
? The Unicode Standard Tab Character (U+0009) ? ;
line feed character =
? The Unicode Standard Line Feed Character (U+000A) ? ;
carriage return character =
? The Unicode Standard
Carriage Return Character (U+000D) ? ;
form feed character =
? The Unicode Standard Form Feed Character (U+000C) ? ;
next line character =
? The Unicode Standard Next Line Character (U+0085) ? ;
line separator character =
? The Unicode Standard
Line Separator Character (U+2028) ? ;
paragraph separator character =
? The Unicode Standard
Paragraph Separator Character (U+2029) ? ;
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7"
| "8" | "9";
at symbol = "@";
assignment symbol = "=";
end sentence symbol = ";";
start group symbol = "(";
end group symbol = ")";
start declaration symbol = "{";
end declaration symbol = "}";
backslash symbol = "\";
start attribute selector symbol = "[";
end attribute selector symbol = "]";
start delimited comment symbol = "/*";
end delimited comment symbol = "*/";
start single line comment symbol = "//";
dot symbol = ".";
comma symbol = ",";
underscore symbol = "_";
hyphens symbol = "-";
escaped single quote symbol = "\'";
escaped double quote symbol = '\"';
single quote symbol = "'";
double quote symbol = '"';
increment operator = "++";
decrement operator = "--";
unary operator = "+" | "-" | "!" | "~"
| increment operator
| decrement operator;
operator = "*" | "/" | "%" | "+" | "-" | "<<" | ">>" | "<"
| ">" | "<=" | ">=" | "==" | "!=" | "&" | "^" | "|"
| "&&" | "||";
unary selector operator = "$", ".", "#", "?", " ";
selector operator = ">", "<", "+", "-", "~", "^", ":",
"::", "%", "&", "|", "\", "/";
selector expression operator = "*" | "/" | "%" | "+" | "-"
| "<<" | ">>" | "<" | ">" | "=" | "&" | "^" | "|"
| "<=" | ">=" | "==" | "!=" | "*=" | "/=" | "%="
| "+=" | "-=" | "&=" | "^=" | "|=" | "$=" | "~="
| ".=" | "#=" | "?=" | ":=" | "&&" | "||";
universal selector = "*";
(**
* MODO LANGUAGE DEFINITION Part II
* ---------------------------------
* Identifier, expression and other lexical units
*)
(**
* Directive Definition
*)
directive = {blank},
at symbol,
identifier,
{blank}-,
expression,
{blank},
end sentence symbol;
(**
* Rule Definition
*)
rule = {blank},
at symbol,
{blank},
start group symbol,
{blank},
expression,
{blank},
end group symbol,
{blank},
start declaration symbol,
{blank},
modo,
{blank},
end declaration symbol;
inline rule = {blank},
at symbol,
{blank},
start group symbol,
{blank},
expression,
{blank},
end group symbol;
(**
* Declaration Definition
*)
declaration = {
assignment
| basic declaration
| extended declaration
};
(**
* Comment Definition
*)
comment = delimited comment
| single line comment;
delimited comment = {blank},
start delimited comment symbol,
({character} - end delimited comment symbol),
end delimited comment symbol;
single line comment = {blank},
start single line comment symbol,
({character} - new line),
new line;
blank = whitespace | comment;
(**
* Other lexical units
*)
string = (
single quote symbol,
single quote escaped string,
single quote symbol
)
|
(
double quote symbol,
double quote escaped string,
double quote symbol
);
single quote escaped string = {
(any Unicode character - single quote symbol)
| escaped single quote symbol
};
double quote escaped string = {
(any Unicode character - double quote symbol)
| escaped double quote symbol
};
integer = "0" | (digit - "0", {digit});
constant = integer,
[
dot symbol,
{digit}-
];
expression = {blank},
{start group symbol},
{blank},
operand | expression,
{
{blank},
operator,
{blank},
{start group symbol},
{blank},
operand | expression,
{blank},
{end group symbol},
},
{blank},
{end group symbol};
member method name = identifier;
identifier = {letter | underscore symbol}-,
{
digit
| letter
| underscore symbol
};
operand = {start group symbol},
{blank},
(
string
)
|
(
[
unary operator
- (increment operator | decrement operator)
],
{blank},
constant
)
|
(
[unary operator],
{blank},
rhs selector
)
|
(
rhs selector,
{blank},
increment operator | decrement operator
)
|
(
[
unary operator
- (increment operator | decrement operator)
],
{blank},
member method name,
{blank},
start group symbol,
{blank},
[
expression,
{
{blank},
comma symbol,
expression
}
],
{blank},
end group symbol
),
{blank},
{end group symbol};
assignment = {blank},
lhs selector,
{blank},
assignment symbol,
{blank},
expression,
{blank},
[inline rule],
{blank},
end sentence symbol;
basic declaration = {blank},
lhs selector,
{blank},
start declaration symbol,
{blank},
modo,
{blank},
end declaration symbol;
extended declaration = {blank},
lhs selector,
{blank},
assignment symbol,
{blank},
rhs selector,
{blank},
start declaration symbol,
{blank},
modo,
{blank},
end declaration symbol;
lhs identifier = {
letter
| underscore symbol
| hyphens symbol
}-,
{
digit
| letter
| underscore symbol
| hyphens symbol
};
lhs selector = (
{blank},
universal selector | selector operand,
{blank},
{
selector operator,
{blank},
selector operand
}
),
{
{blank},
comma symbol,
{blank},
lhs selector
};
rhs selector = {blank},
[unary selector operator],
identifier,
{rhs selector};
selector operand = {blank},
[
[unary selector operator],
lhs identifier
],
{blank},
[
(
start group symbol,
[
selector expression,
{
{blank},
comma symbol,
{blank},
selector expression
}
],
{blank},
end group symbol
)
|
(
start attribute selector symbol,
selector expression,
{
{blank},
comma symbol,
{blank},
selector expression
},
{blank},
end attribute selector symbol
)
],
{selector operand};
selector expression = {blank},
{start group symbol},
{blank},
operand | expression,
{
{blank},
selector expression operator,
{blank},
{start group symbol},
{blank},
operand | expression,
{blank},
{end group symbol},
},
{blank},
{end group symbol};
(**
* MODO LANGUAGE DEFINITION Part III
* ----------------------------------
* Final Modo definition
*)
modo = {
directive
| rule
| declaration
| comment
};
Appendix B. Bibliography
- Berners-Lee T., Hendler J., Lasilla O., The Semantic Web, Scientific American 284, 34 - 43, 2001
- Booch, G., Jacobson, I. and Rumbaugh, J., OMG Unified Modeling Language Specification, Version 1.3 1st Edition, Object Management Group (OMG), 2000.
- Bos, B., Çelik, T., Hickson, I. and Lie, H. W. (Eds.), Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification, W3C Candidate Recommendation 23 April 2009, World Wide Web Consortium (W3C), http://www.w3.org/TR/CSS2/, Last Access: 02.06.2009.
- Calvary, G., Coutaz, J., Thevenin, D., Limbourg, Q., Bouillon, L. and Vanderdonckt, J., A Unifying Reference Framework for multi-target user interfaces, Interacting with Computers 15, 289 - 308, 2003.
- ECMA-334, C# Language Specification, 4th Edition, ECMA International, 2006.
- Gosling, J., Joy, B., Steele, G. and Bracha, G., The Java language specification, 3rd Edition, Addison-Wesley, 2005.
- Heng, B.C.P. and Mackie, R.I., Using design patterns in object-oriented finite element programming, Computers and Structures 87, 952 - 961, 2009.
- Horsburgh, J.S., Tarboton, D.G., Piasecki, M., Maidment, D.R., Zaslavsky, I., Valentine, D. and Whitenack, T., An integrated system for publishing environmental observations data, Environmental Modelling & Software 24, 879 - 888, 2009.
- ISO/IEC 14977, Information technology - Syntactic metalanguage - Extended BNF, 1st Edition, International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), 1996.
- Kernighan, B., and Ritchie, D., The C Programming Language, 1st Edition, Prentice Hall, 1978.
- Kim, K.S., Information seeking on the Web: Effects of user and task variables, Library & Information Science Research 23, 233 - 255, 2001.
- Lam, D. and Swayne, D., Issues of EIS software design: some lessons learned in the past decade, Environmental Modeling & Software 16, 419 - 425, 2001.
- Laporti, V., Borges, M.R.S. and Braganholo, V., Athena: A collaborative approach to requirements elicitation, Computers in Industry 60, 367 - 380, 2009.
- Park, K.S. and Lim and C.H., A structured methodology for comparative evaluation of user interface designs using usability criteria and measures, International Journal of Industrial Ergonomics 23, 379 - 389, 1999.
- Rau, P.P., Choong, Y. and Salvendy, G., A cross-cultural study on knowledge representation and structure in human computer interfaces, International Journal of Industrial Ergonomics 34, 117 - 129, 2004.
- Reinhartz-Berger, I. and Sturm, A., Utilizing domain models for application design and validation, Information and Software Technology 51, 1275 - 1289, 2009.
- Schwabe D., Rossi G., An Object Oriented Approach to Web-Based Applications Design, Theory and Practice of Object Systems 4, 207 - 225, 1998
- The Unicode Standard, Version 4.1.0, The Unicode Consortium, Boston, MA, Addison-Wesley, Available at http://www.unicode.org/versions/Unicode4.1.0/, Last Access: 02.06.2009, 2003.
- Tom, A., Inside C#, Microsoft Press, 2001.
- Wirth, N., The Programming Language Pascal, Acta Informatica 1, 35 - 63, 1971.