Hacker News Reader

Comment by otabdeveloper1 | Hacker News Reader

Someone's been confusing syntax and internal representation again.

Simple: parse

  <foo bar="zot">quux</foo>

as (JSON-like)

  { 
    "foo": {
       "bar" : "zot",
       "" : "quux"
     }
  }

Problem solved, XML is now logical again.

View on HN

There is an existing alternative syntax for XML data [1] that represents it as a list of key-value pairs where the keys are XPath-like paths. In this syntax

  <foo bar="zot">quux</foo>

would be represented as

  /foo/@bar=zot
  /foo=quux

I think data serialization formats of this particular kind are underused. They are dead simple to parse while still being reasonably human-friendly (more so than XML, I'd say). Get rid of the attributes and introduce the convention that nodes with children named "0", "1", ... , "$N" are arrays and you can represent JSON.

[1] http://www.ofb.net/~egnor/xml2/

I like this, I had an instinct about making a file format similar to this, except pushing the path onto a stack.

    [foo]
    @bar="zoot"
    
    [baz]
    "quux"
    
    []
    []

I figured you would save a little in the serialization. In practice I rarely need such a thing, and just serialize a structure to whatever I'm working with (s expressions, or in java xstream etc since those xml files are read somewhere...)

When you say that someone's been confusing syntax and internal representation, are you speaking of yourself? You don't parse XML as JSON, though you might parse XML and serialize the resulting internal representation as JSON. Also, XML is the syntactic representation of the document model, so your JSON isn't XML because it's a different sequence of characters.

That said, the JSON representation has a bug: what if there are multiple child elements? A fix would be using numeric indices for the children rather than the empty string. Then it would look both like an object with keys (attributes) and an array (of elements). Though, if you want to serialize that back into XML, you would need to make sure you never use non-strings as attribute values! Another bug is that the objects don't maintain their tag name; writing code to process data in this representation would be fairly annoying because a pointer to an element would be an object plus a key, rather than just an object. A fix for this would be to have a "tag" key inside the object.

This does not do away the distinction between attributes and content -- that attributes are flat strings while content can be nested.

Slow clap

Reply on news.ycombinator.com