Six Things You Need (was) {mark} - a new simple notation that unifiesJSO

Getting critical mass in terms of take-up of an idea like this is not easy. Preconditions include:

* a clean design

* open source implementations for a sufficient number of important platforms

* a strong recognition in the user community that existing solutions aren't good enough

* early influential adopters

* a competitive technology stack including tools for authoring, editing, validating, transforming

* a large amount of luck

One might staple Mike's admirable "what you need" list to, um, every new technical proposal on Earth ... though in practice, I suspect that four out of six often are enough, and some of them can be developed over time.

But then there's this too:
Alain Couthures <alain.couthures@agencexml.com>:

I am afraid that just big companies can specify notations which will become successful because they will also provide engines to process them and because, then, people will be eager to announce that they are experts for them...

Cordially, Jamie

James Bryce Clark, General Counsel
OASIS: Advancing open standards for the information society
https://www.oasis-open.org/staff
www.twitter.com/JamieXML

OASIS+FIRST.org Borderless Cyber Prague Dec 2017: j.mp/praguecybersec
EU Commission Rolling Plan for Open ICT Standards: j.mp/EUstds2017
Cybersecurity standards at RSAc 2017: j.mp/OASIS2017RSA

On Thu, Jan 25, 2018 at 9:24 AM, Michael Kay <mike@saxonica.com> wrote:

There are many similarlities with FtanML: https://www.balisage.net/Proceedings/vol10/html/Kay01/BalisageVol10-Kay01.html

It's not clear what mixed content ends up looking like: getting that right is one of the key design challenges.

Getting critical mass in terms of take-up of an idea like this is not easy. Preconditions include:

* a clean design
* open source implementations for a sufficient number of important platforms
* a strong recognition in the user community that existing solutions aren't good enough
* early influential adopters
* a competitive technology stack including tools for authoring, editing, validating, transforming
* a large amount of luck

Michael Kay
Saxonica
On 25 Jan 2018, at 16:43, Henry Luo <henry@perpetuatech.net> wrote:
Dear all,
I am happy to announce the first public beta release of Mark - a simple notation that unifies JSON and XML.

You can find out more about it at https://mark.js.org/
Objective Markup Notation, abbreviated as Mark or {mark}, is a new unified notation for both object and markup data. The notation is a superset of what can be represented by JSON, HTML and XML, but overcomes many limitations these popular data formats, yet still having a very clean syntax and simple data model.

Mark Sample

Below is a sample Mark object, representing a simple registration form:
{form                                   // object type-name 'form'
  {!-- comment --}                      // Mark pragma, similar to HTML comment
  {div class:"form-group"               // nested Mark object
    {label for:"email"                  // object with property 'for'
      "Email address:"                  // text needs to be quoted
    }
    {input type:"email", id:"email"}    // object without any contents
  }
  {div class:"form-group"
    {label for:"pwd" "Password"}
    {input type:"password", id:"pwd"}
  }
  {button class:['btn','btn-info']      // property with complex values
    'Submit'                            // text quoted with single quote
  }
}
Mark Data Model
Mark object has a very clean and simple data model. Each Mark object has 3 facets of data:

Type name, which is mapped to object.constructor.name under _javascript_.

Properties, which is a collection of key-value pairs, stored as normal _javascript_ named properties.

Contents, which is a list of content objects, stored as indexed properties inside the same _javascript_ object.

Mark utilizes a novel feature in _javascript_ that a plain JS object is actually array-like. It can contain both named properties and indexed properties.
Mark vs. JSON
Mark is a superset of JSON. It extends JSON notation with a type-name, and a list of content objects. Comparing to JSON, Mark has the following advantages:

It has a type-name, which is important in identifying what the data represents; whereas JSON is actually an anonymous object, missing the type name.

It can have nested content, which is common in all markup formats, and thus allows Mark to convenient represent document-oriented data, which is awkward for JSON.

It incorporates most of the enhancements of JSON5 to JSON (e.g. allowing comments, property name without quotes, etc.), and makes the format more friendly for human.

Some disadvantages of Mark, comparing to JSON would be:

It is no longer a strict subset of _javascript_ in syntax, although a Mark object is still a simple POJO.

It does not yet have wide support, like JSON, at the moment.
Mark vs. XML
Comparing to XML, Mark has the following advantages:

Mark properties can have complex object as value; whereas XML attribute values always need to be quoted and cannot have complex object as value, which is not flexible in syntax and data model.

Mark syntax is much cleaner than XML. It does not have all the legacy things like DTD, and it does not have whitespace ambiguity.

The data model produced by Mark is fully typed, like JSON; whereas XML is only semi-typed without schema.

What do you think?

With an unified notation and data model, one set of tools (parser, selector, query, validator, transformer, ...) can be used to process data previously stored in JSON, HTML or XML.
Do you thing Mark is a better generic data format than JSON or XML? Do you think it is worth all the effort to migrate to this new notation? ...

Looking forward to hear your feedback!
Regards
Henry