The white space is always significant in
mixed content.
But if this is allowed then I think the
mixed content requirement is satisfied and in a natural and
XML-similar way.
E.
Thanks, Eliot for your fast response.
How would XML mixed content be encoded
in mark?
That is, if I have
<root>text1 <foo/>
text2</root>
What does that look like in mark?
Otherwise, based on a first reading, it
looks, syntactically, like it is structurally equivalent to
XML except as regards attributes (in that structures within
properties in mark could not be translated directly to XML
attributes but could be translated to nested elements.
That is, there’s semantically no
difference between
{root
prop: { foo: “bar”, baz: “blorg” }
}
And
{root
{prop foo: “bar”, baz: “blorg”}
}
In both cases the label “prop” is
associated with the atomic properties foo and baz. (Which
brings us back to the eternal “attributes or subelements?”
question)
But I will observe that, while in XML the
difference is very large syntactically, here in mark is
quite small, which is interesting.
I definitely like having the explicit
type label.
I will also observe that mark, with
attributes restricted to simple values, could be defined as
an alternative SGML syntax, as far as I can tell (without
actually trying it, who actually remembers SGML syntax
declaration syntax any more, or even has tools on hand to
validate it?).
I’ve been doing work with MarkLogic
lately, where you can use JSON instead of XML or
explicitly-constructed maps to pass data structures around.
I think I would find mark a syntactically-convenient
alternative to XML and JSON for that purpose: I find it
annoying that JSON does not have mark’s object type label
but XML syntax is verbose when you’re just trying to create
a data structure that’s not just a set of name-value pairs.
But I wouldn’t use mark for existing XML
applications where XML is primary human-authored source, for
a number of reasons.
Cheers,
E.
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
