xml redundancy

Robustness?

Is this not easier to correct when there are closing tags present?

  <b1>    <c1>...</c1>    <c2>...</c2>  -- missing </b1> --  <b2>    <c1>...</c1>    <c2>...</c2>  </b2>  <b3>    <c1>...</c1>    <c2>...</c2>  </b3>

Kind of reminds me of XML versus s-expressions. You would prefer something like SXML?

Also, I think the ending tags aren't necessarily the major source of redundancy. You should perhaps fight for a binary XML format.

Redundancy is good, it helps you correct errors.

If you wanted compactness, you'd be storing the data in some binary format instead.

Quote:

Original post by SamLowryAlso, I think the ending tags aren't necessarily the major source of redundancy. You should perhaps fight for a binary XML format.

Ha, good point, true that. Well, it's also possible to just zip the xml file and it's as binary as you can get.

My original question is answered pretty well, thanks all :)

SGML does in fact support some tag abbreviations, such as or 123

It's supposed to be human readable, and we don't all dream in Lisp

Quote:

Original post by SamLowry You should perhaps fight for a binary XML format.

There is already one :-) EBML

EBML format (used for the Matroska video container)

I still prefer JSON for this type of document. Though XML is a lot more useful for general markup of text (e.g. TEI, HTML).

xmlsucks.org

Quote:

Original post by Lode Everything is done with xml these days, which is great, the concept of such a tree structure in documents works great. But why's there the redundancy in it where the name of an element is repeated twice? It can be perfectly deduced what end tag belongs to what element just like finding matching bracket pairs, there's no need to repeat the name there. I can at least find two alternatives for the following structure: <Alpha> <Beta Gamma="Hi">Hello</Beta> <Delta/> </> <Epsilon> <Zeta>123</Zeta> </Epsilon></Alpha> Alternative 1: <Alpha> <Beta Gamma="Hi">Hello</> <Delta/> < /> <Epsilon> <Zeta>123</> </></> Alternative 2: <Alpha/ <Beta Gamma="Hi"/Hello> <Delta/> </> <Epsilon/ <Zeta/123> >> Why didn't something like that become the hugely adopted standard instead of the version where tagnames are repeated twice?

Because people don't like Lisp, unfortunately.

(alpha  (beta :gamma "hi" "Hello")  (delta)  (epsilion    (zeta 123)))

The idea of using Lisp as a data format is one that intrigues me quite a bit. The structure is rather a lot simpler than XML, andit's way more compact. I'd still hate to code in Lisp, but as a data interchange format, it seems like a really nice alternative.

I think I'd prefer the alternative XML formats if I could be assured I'd only be creating/editing them in a well-featured IDE. It follows that because many people use the wrong tools for the job (example: notepad/emacs/vim/etc -- for coding) that I know the alternative XML formats would cause alot more evil than good; I don't think I even need to clarify this.

In my prototypic "data-stream" version of my Frostwinds engine, I'm being introduced to XML and relying on it heavily. And I'm pausing quite frequent to ponder whether I could be using XML more efficiently/(less redundant)/effectively due to how much freedom we have in designing our data structures.

Example: An RPG character's data.

Store everything in attributeless elements.
53
26

Store everything in single element, as attributes.

All of the above -- sorta.
health
mana

Quote:

Original post by GnuVince Why didn't something like that become the hugely adopted standard instead of the version where tagnames are repeated twice?

Because people don't like Lisp, unfortunately.

(alpha  (beta :gamma "hi" "Hello")  (delta)  (epsilion    (zeta 123)))

[/quote]

I think this highlights why XML uses verbose closing tags. The more complex your hierarchy gets, the more difficult it gets to visually parse it.

Since one of the requirements of XML was to be human readable, this makes sense.

Of course, in my opinion, one would have to be mad to read/write XML by hand, but at least it makes sense in context.


To me, I like XML because no matter where I go, there's an XML parsing library already written for me. You don't really get that with any other format. That offsets the downsides, in my opinion.

I feel the need to further stress my point; "dependence on a good IDE".

Let's consider XHTML. Often I'll inspect the output of my CGI-C# or ASP.NET httpHandlers in the browser (either via view-source, or as a page rendered by W3C's XHTML checker). As these are generated via code, they are scarcely tabbed properly, and so the output of various sections is often a line.


..."
[Line 293 of "http://www.frostwinds.com/Forum"]

Trying to debug, or determine where the point of insertion of something (eg, ""), is made easy to do, in even primitive things like notepad or a terminal (SSH / Dos / etc), with this output; you're not mad to read/edit the above line by hand.

Contrast this with one of the purposed XML alternatives..

"...
..."

Again, this wouldn't be a problem to do in an IDE made for editing this stuff. But since I cannot embed a "Visual Web Developer 2008: IDE" control on a WinForm, or WebPage, or provide even similar functionality in a ConsoleApplication, this is why it'd never be adopted.

[Edited by - Thevenin on March 1, 2008 9:08:32 PM]

... but how are you supposed to edit that kind of stuff in vi? or Emacs? or Notepad? I think that's the main reason behind it - a lot fo xml structures are edited using text editors and the extra bits in the closing tag make it more readable.

Quote:

Original post by speciesUnknown ... but how are you supposed to edit that kind of stuff in vi? or Emacs? or Notepad? I think that's the main reason behind it - a lot fo xml structures are edited using text editors and the extra bits in the closing tag make it more readable.

A lot of the above examples would work well in a text editor with matching bracket highlighting.

I always liked this format, personally:

alpha{  beta : gamma="hi"  {    hello  }  delta  epsilon  {    zeta    {       123    }  }}

Works nicely in most existing editors, and no redundancy. Minor variants are usually helpful to assist with domain-specific requirements.

I had to work on an Eclipse IDE tool at IBM that handled GML markup. Off the top of my head I think GML became SGML which eventually became XML.

It had the idea of context-defined end tags, something like:

:p.piece of text:ep.:p.another piece:ep.

Where you had an 'ep' to explicitly end a 'p' tag, but you could legally have things like:

:p.piece of text:p.another piece:ep.

Because the rules stated that 'p' elements couldn't be nested, therefore a new 'p' appearing inside a 'p' implied that the second 'p' should be immediately preceded by an 'ep'.

Writing a parser for that was a fun task. Especially as it also had C, Z-series assembler, REXX and PL/X code thrown into the same file(s) [lol]


Jack