How to Avoid Being Called a Bozo When Producing XML (2005)

You're really asking a different question here: "Why should an integer be used as a task ID?" Storing the task ID as a string may give you options in the future that you wouldn't otherwise have, at a relatively small cost in parsing performance and validation overhead.

Most of the world's regrettable XML schemas were faulty at the specification stage, not the implementation stage. To minimize the likelihood of eventual regret, I usually prefer to store stuff in strings unless there's a very good reason not to. The fact that I'm using XML means that I'm not that concerned about performance, so... strings, it is.

A similar argument can be applied to the child/attribute dilemma. If there's even the slightest chance that a field isn't always going to be a leaf node, I'll do the extra typing and make it a child. Ideally the parser would be written to make them both work the same anyway.

Then just change '' to '(tagname,' and '' to ')' and you'll have S-expressions.

Consider this:

    (feed
     (version 1)
     (title "Example Feed")
     (link http://example.org/)
     (updated "2003-12-13T18:30:02Z")
     (author (name "John Doe"))
     (id urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6)
    
     (entry
      (title "Atom-Powered Robots Run Amok")
      (link http://example.org/2003/12/13/atom03)
      (id urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a)
      (updated "2003-12-13T18:30:02Z")
      (summary "Some text.")))

    
    
    
    Example Feed
    
    2003-12-13T18:30:02Z
    
    John Doe
    
    urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
    
    
    Atom-Powered Robots Run Amok
    
    urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
    2003-12-13T18:30:02Z
    Some text.
    
    
    

And compare to your proposed version:

    
    
    Example Feed
    http://example.org/
    2003-12-13T18:30:02Z
    
    John Doe
    
    urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
    
    
    Atom-Powered Robots Run Amok
    http://example.org/2003/12/13/atom03
    urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
    2003-12-13T18:30:02Z
    Some text.
    
    
    

Take a look at https://news.ycombinator.com/item?id=12198581; I think it demonstrates how readable one dialect of S-expressions can be.

> I also can't see how they map easily into datastructures of imperative programming languages

JSON consists of numbers, strings, booleans, objects and arrays; canonical S-expressions consist of bytes and lists. I contend that one can easily encode strings, numbers and booleans alike as bytes, and both objects and arrays as lists. Consider:

    {

        "id": 1234,

        "isEnabled": true,

        "props": ["abc", 123, false],

    }

    (object

     (id "1234")

     (is-enabled "true")

     (props (abc "123" "false")))

And I honestly think that the S-expression version is far more attractive.

I have been forced to use XML one way or another for a variety of uses (mostly integration, not document storage - but still), and have not ONCE had a use for namespaces or multiple DTDs in a single document. I suspect no one has statistics, but I wouldn't be surprised if this is true for 99.9% of {users,documents,systems} - which, if true, means that 1/1000 burdens the rest needlessly. But of course, this is mere speculation.

> I also do subscribe to formal grammars, mature standards, and good documentation.

XML is enticing by appearing to have those, but it actually doesn't, as Naggum articulated in[0]. XML schemas can describe a superficial structure, but not anything non-trivial and definitely not any semantics. Naggum is entertaining though he holds nothing back, see e.g. [1].

> It's just that I think XML got an undeserved bad reputation and many of the 'good parts' have been forgotten.

The problem with XML is that, like lawyers, 95% of the population gives an undeserved bad reputation to all the rest. XML did have some good ideas, but they are almost nowhere to be find in practice.

> This allows us to connect, say, 'com.facebook:Person' with 'com.google:Person' with a global equivalence relation. It allows us to specify bridges between standards.

No it doesn't, unless they are semantically equivalent - which they never are. They might be superficially similar, with some translation possible using (e.g.) XSLT. But if, for example, com.google:Person has and no first/middle/last, and com.facebook:Person has , and (but no display name), then XSLT can only translate one way, and nothing can translate the other way without error. It's nice in theory, but - projecting from my experience which is long and across many industries, but obviously still anecdotal - in practice, the semantic differences always require logic beyond XSLT, and thus the namespaces are only of aesthetic value if any.

> It is only valid when it can be interpreted by a receiving program (otherwise it is data, not information)

True. How is that different than XML or anything else? The same statement applies to XML, namespaces or not. If the program doesn't know what it is interpreting, the namespaces do not matter. If it does know, they don't matter either. Sure, it's a way to mark the source through _all_ elements, but since the program must be aware anyway, you can just as well enclose your Person object with {Facebook: {first:'John', last:'Smith'}} or {Google: {display:'John Smith'}}. Yes, XML has a standard way of doing that - but in practice my experience that it costs about 1000 times what it provides.

> With versioning, I meant schema versioning. Admittedly, not a great solution, but at least it allows a receiving party to know which parts can safely be interpreted.

And what if semantically, the parts you don't know about make interpretation moot? Practically, if it's a version you don't know, you shouldn't try to interpret it. And that's achieved by a simple 'version' field in JSON. The standard way of doing this buys practically nothing - 99% of XML files out there do not declare or properly follow a DTD.

[0] http://www.xach.com/naggum/articles/3224504693262432@naggum.... [1] http://www.schnada.de/grapt/eriknaggum-xmlrant.html