("This is a test",<foo>This is <bar>an element</bar> inside an element</foo>,12,25,<bin bat="term">More text</bin>)
("This is a test", element foo {('This is ',element bar {'an element'},' inside an element.')},12,25,element bin {(attribute bat {"term"},"More text"}))
("This is a test",*foo: ("This is ",*bar: ('an element'),'inside an element'),12,25,*bin: (@bar: "term","More text"))
You could even go a step further by assuming that the constructs *foo: () automatically "escapes out" of text. Additionally sequence items that need to be separated could be placed in a [] structure:
(This is a test *foo: (This is *bar: (an element) inside an element),[12,25],*bin: (@bar: (term) More text))
HTML would be encoded as *html: (*head: (*title: (This is the top title) *link: (@rel: (stylesheet) @href:(my.css)) *body: (*h1: (This is the page title) *p:(This is a *b: (test).)))
Finally, it may be possible to eliminate the * notation altogether:
html: (head: (title: (This is the top title) link: (@rel: (stylesheet),@href: (my.css)) body: (h1: (This is the page title) p: (This is a b: (test).)))
This doesn't break XML, beyond the document vs. grove issue (which has always been one of the more questionable characteristics of the XML spec), is compact, more or less readable, and can be readily mapped to JSON. For instance, consider a structure of the form:
For instance, a list of strings could be differentiated with []:
colors: (["red","green","blue","yellow"])
JSON would interpret this as:
{colors: ["red","green","blue","yellow"]}
while XML would interpret it as
<colors xsi:type="xs:NMTokens">red green blue yellow</colors>
or, worst case:
<colors>
<xml:null>red</xml:null>
<xml:null>green</xml:null>
<xml:null>blue</xml:null>
<xml:null>yellow</xml:null>
</colors>
(The case of a list of strings is one where the XDM is superior to the serialization model, since the angle bracket serialization has no notion of the concept of a list).
This is a declarative description, not a functional one, but that doesn't mean that you couldn't take advantage of XQuery like constructs:
let $title1 := "This is the top title"
let $title2 := "This is the page title"
let $page := html: (head: (title: ({$title1}) link: (@rel: (stylesheet) @href: (my.css)) body: (h1: ({$title2}) p: (This is a b: (test).)))
return $page
and as white space isn't that much of a concern:
let $page :=
html: (
head: (
title: ({$title1})
link: (
@rel: (stylesheet)
@href: (my.css)
)
)
body: (
h1: ({$title2})
p: (This is a b: (test).)
)
)
Note that this is the primary reason why I haven't used the curly brace for this particular notation; it's become too thoroughly established as an escape mechanism for the underlying scripting environment.
Finally, taking Michael Kay's example:
{ authors: [
{name: "Michael Kay", affiliation: "Saxonica"},
{name: "Liam Quin", affiliation: "W3C"}
]
abstract:<para { style : "bold" }>Here be some dragons</para>
content:<section { numbers : [1,1,2] }><para>...</para></section>
}
remap that in the above notation:
(authors: (
[null: (name: (Michael Kay) affiliation: (Saxonica)),
null: (name: (Liam Quin) affiliation: (W3C))]
abstract: (para: (@style: (bold) Here be dragons)
content: (section: (numbers: ([1,1,2]) para: (...))
)
or, if you use the notation : ( by itself to indicate an "anonyous" class:
(authors: (
[ : (name: (Michael Kay) affiliation: (Saxonica)),
: (name: (Liam Quin) affiliation: (W3C))]
abstract: (para:(@style: (bold) Here be dragons)
content: (section:(numbers: ([1,1,2]) para: (...))
)
Seems pretty straightforward to me, should be fairly easily parseable, and has the advantage of being trivial to wrap within a string. Additionall, "foo : (bar)" is not exactly a common construct lexically, even without whitespace, and escaping it could simply involve the use of a construct such as `foo: (bar)`, with the "`" character indicating that the string should be interpreted literally.
The exact nature of the notation can be argued, but I think the important point to consider is that while the serialization model of XML is not fully congruent with JSON, XDM is. Which means that any discussion about a MicroXML needs to be looking at XDM, rather than the XML 1.0 serialization model, as the basis for that simplification.
This is something that I think has been missing in all of the discussions thus far. This is not a notational issue, it's a data modeling one. There are simply constructs that cannot be modeled readily in JSON that are easily rendered in XML angle bracket notation (ABN) and vice versa, because ABN has no mechanism for defining arrays that doesn't rely either upon a convention (white space NMTokens) while JSON notation for handling semi-repeating XML structures (such as <a>1</a><a>2</a><b>3</b><a>4</a>) can get hideously complex fast. Yet an XDM notation could represent both cases trivially.
Kurt Cagle
Invited Expert, Forms Working Group, W3C
443-837-8725
On Tue, Feb 15, 2011 at 10:49 AM, Michael Kay
<mike@saxonica.com> wrote:
But then looking at Mikes
{ authors: [
{name: "Michael Kay", affiliation: "Saxonica"},
{name: "Liam Quin", affiliation: "W3C"}
]
abstract:<para { style : "bold" }>Here be some dragons</para>
content:<section { numbers : [1,1,2] }><para>...</para></section>
}
I'm not sure if content: is markup? I can see authors as a list..
Is content: wrapping<section/>
affiliation : "Saxonica"
is a name-value pair (within a map) where the name is affiliation and the value is a string, so
content: <section><para>...</para></section>
is a name-value pair (within a map) where the name is content and the value is a (textual) element.
This is what I mean about composability between structured data and marked-up text, without being forced to represent the structured data using syntax that was designed for textual markup. (Not dissimilar from putting XML in a column of an RDB, except that (a) the structured data part is more powerful than rows-and-columns, and (b) you can have structured data inside the text content as well as vice versa.)
Michael Kay
