This is originally an issue on github. I provided a definition and closed the issue. But the discussion continued, as we can't be sure how best to present Tokenscript to the existing blockchain communities.
There are a few approaches. Since "Tokenscript to Token is like HTML to Information", The first is to copy the definition of HTML.
HTML enabled the Web. An HTML document consists of structured information with hyperlinks.
The difficulty of copying this style of definition is that it assumes the audience knows what is "The Web", which is a result of HTML.
Let me improvise:
Tokenscript enables Tokenisation. A TokenScript document consists of token's smart contract addresses, interfaces, actions that can be performed on the token and the UI to render the token.
The issue here is true tokenisation is rarely done (read the design paper for why). Once it is done, of course, Tokenscript will have been well known already, and not needing us to agaonise over its definition.
The second attempt is to re-use the design paper for definition.
The description in the readme is a good abstract:
Today, the way tokens are accessed, rendered and transacted are scattered across Dapps and Smart Contracts. All knowledge about rendering a token and constructing a transaction about the token is in a "host" DApp. The "host" DApp becomes a centre in the token's marketisation and integration, recreating data interoperability, security and availability barrier - precisely the same set of issues that prevented tokenisation before blockchain's invention.
TokenScript allows token logic and rendering to be separated out of the "host", allows token to be easily portable and market to be created for it.
It allows different token providers to, not only describe the features of their tokens but also how they are allowed to “act”, e.g. transferability. The crux of the idea is that such a markup description can be updated at any time by the token issuer and retroactively reflect the behaviour of already issued tokens. Besides allowing easy interoperability between different token providers, this also eliminates the need to update the DApp or smart contract whenever the business logic of a particular type of token changes.
I think it's a good definition. The problem of this one is it's too long and not very interesting to a Dapp developer.
The 3rd try is reflected in the pull-request #56 against the git repo's README. It is a conversational style to introduce Tokenscript, so it's more fit for 𝑖𝑛𝑡𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑜𝑛 then 𝑑𝑒𝑓𝑖𝑛𝑖𝑡𝑖𝑜𝑛.
TokenScript builds the front end logic of a token dapp with the smart contract on the backend. A TokenScript file contains a token's business logic, token UI rendering and program interface, signed by the token's modeller.
"Don't we already have a front-end for tokens?" You might ask
In Ethereum, most tokens have a web application which serves all the content relevant to the token. Let's call it the "Dapp" of the token.
If everything the user wanted to do with that token is done on that website, then yes there is already a front-end for that token. But that token isn't very useful as a blockchain token, since it can't be used on other Dapps.
TokenScript of a token is like making the dapp of the token portable and usable across multiple dapps. In this frameworkd, a dapp can provide services and context related to the token (e.g. you have one sword in the WoW dapp and an assault rifle in call of duty).
This distinction and separation is important for tokenisation - a concept addressed in the design paper. The authors of the design paper holds that there is no tangbile benifit of using blockchain without tokenisation.