Possible Xml Replacement

Some find languages with < > in them hard to read. This page sprouted from LispVsXml.

I think that < > is very hard on the eyes.. I'm not too much of a fan of html and xml for that reason alone, actually.

Has any one done any eye studies showing what annoys programmers? I do find < > annoy me.

Okay, so it's not just the < > , it's also the verboseness too, or at least the fact that we are forced to be verbose in xml and html.

Some syntax suggestions are below. Are they:

...Is easier to read than XML. Easier on the eyes
...Makes more logical sense
...Reduces verboseness where possible, but allows verbosness where needed as an option, not a requirement.
...Easier to read at breakfast when printed off a laser jet printer (you do print your code out, don't you?)
...Would be an easy step out of xml (i.e. easy to learn and pick up if you already know XML)
- i.e. this would be an easy port for both the human and the computer.. could easily convert all your exist xml/html documents over to an easier to read syntax. Parsers would have to be modified.. but no kidding. It would be for the better.

So here are some language syntax suggestions (projects? domain.org anyone?) that I'd like to look into as possible replacements for XML or HTML.

Do you, or do you not find these proceding syntax styles easier to read than XML? So why would you not you use them? Why continue XML? Why continue HTML? I am seriously considering what annoyances the < > symbols and languages cause me.

Possibility 1:

 {dictionary}

{word}
xml:=id;
data language:=def;

{word}
java:=id;
programming language:=def;

{word}
lisp:=id;
programming and data language:=def;

Possibility 2:

 (dictionary)

(word)
 xml:=id;
 data language:=def;

(word)
  java:=id;
 programming language:=def;

(word)
 lisp:=id;
 programming and data language:=def;

Possibility 3:

 [dictionary]

[words]

 xml:=id;
 data language:=def;

  java:=id;
 programming language:=def;

 lisp:=id;
 programming and data language:=def;

[/words]

 [/dictionary]

Possibility 4:

 ⟨dictionary⟩

⟨words⟩

 xml:=id;
 data language:=def;

  java:=id;
 programming language:=def;

 lisp:=id;
 programming and data language:=def;

⟨/words⟩

 ⟨/dictionary⟩

Question: How are multi-line values (text) determined? How is ":=" escaped?

Possibility 5:

 Replace all above := with =

However I find := easier to read.

Possibility 6:

 dictionary {
    word {id=xml, def="data language"}
    word {id=java, def="programming language"}
    word {id=lisp, def="programming and data language"}
 }

Formatting variation of same language:

 dictionary {
    word {
        id=xml, 
        def="data language"
    }
    word {
        id=java, 
        def="programming language"
    }
    word {
        id=lisp, 
        def="programming and data language"
    }
 }

Well, so, argument over XML readability? First..just to refresh your memory.. Remember what XML looks like? (this taken from LispVsXml)

>>> < messy > >>>

 <dictionary>
   <word>
     <id>xml</id>
     <def>data language</def>
   </word>
   <word>
     <id>java</id>
     <def>programming language</def>
   </word>
   <word>
     <id>lisp</id>
     <def>programming and data language</def>
   </word>
 </dictionary>

<<< < messy > <<<

Consider AlternativesToXml. (There are a couple of links to good lists at the end of that page.)

In particular, consider YamlAintMarkupLanguage:

 dictionary:
   - word: xml
     def:  data language
   - word: java
     def:  programming language
   - word: lisp
     def:  programming and data language

-or-

 dictionary:
   'xml'  => 'data language'
   'java' => 'programming language'
   'lisp' => 'programming and data language'

One problem with YAML is it's usage of whitespace for formatting, which makes it more fragile in transport. This can be largely addressed by specifying that it always be binary-encoded in some way, say zip-compressed, but it's still a problem to consider.

I concur. Even this Wiki has TabMunging problems. -t

How about ServiceOrientedDataAccess or soda? Please see http://geekswithblogs.net/rebelgeekz/archive/2004/01/20/1408.aspx . This site gives a brief explanation about the alternative. I haven't been able to find any other site talking about this, though. --SriramGopalan