Re: [xml-dev] XML Redux

[Piotr Bański <bansp@o2.pl>]

Hi Michael,

(full context below)

> For syntax, extend JSON with one additional kind of value - the text
> element - which looks like an XML element today, except that the
> attributes are replaced by a property of an element called its metadata
> which may be any of the above kind of values - most often a map, but not
> restricted.

Just wondering: since you're giving up canonical XML here anyway, would
it not make sense to use e.g. LMNL, to address overlapping hierarchies
-- or could they be handled differently (and still naturally) in the
system you propose?

I realise that the answer may be "you wouldn't use this for overlapping
hierarchies", but they like to pop up anywhere uninvited, it's OHCO that
appears to be the special case, at least for some domains. When I saw
the syntax for the text element that you suggested, LMNL appeared a
minimal modification that might result in a large boost in expressive power.

Thanks,

  Piotr

On 15.02.2011 12:10, Michael Kay wrote:
> On 14/02/2011 18:03, Liam R E Quin wrote:
...
>> http://www.barefootliam.org/xml/20110212-xml-redux
...
>>
> I'm inclined to be much more radical. There's no benefit in making
> incremental improvements that cause a lot of disruption; the world will
> stick with XML as it is today unless something radically better comes
> along. For some applications where XML has been exploited over the last
> ten years, JSON is radically better; for other applications, it's
> hopeless. Let's rethink from the ground up, learning from what has gone
> before in other traditions as well as our own.
> 
> Angle brackets aren't a good way to handle structured data. It's not
> just the end tags that are redundant; there's usually no need to have
> separate names for a collection and its members, and there's no need to
> name each member of a homogeneous collection. They were invented for
> textual markup; let's stop trying to use them for other purposes.
> 
> What data structures do we need? Basically those in JSON, plus
> structured text.
> 
> * Maps (key - value pairs)
> 
> * Sequences of values
> 
> * Strings, numbers, booleans
> 
> * Text elements
> 
> For syntax, extend JSON with one additional kind of value - the text
> element - which looks like an XML element today, except that the
> attributes are replaced by a property of an element called its metadata
> which may be any of the above kind of values - most often a map, but not
> restricted.
> 
> So we might have
> 
> {  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>
> }
> 
> This uses the tagging syntax where it was designed to be used, for
> textual markup; it uses notations designed for structured data when we
> want to hold structured data; and it gives full composability between
> the two - including of course elements within the metadata of another
> element.
> 
> Michael Kay
> Saxonica