Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of COS, or Why I Love JSON and Hate XML

jimpravetz.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: In Defense of COS, or Why I Love JSON and Hate XML

#31

Post by rauar »

patrickg wrote: post #7
billysilly wrote: post #3

Earlier quoted context omitted.

"Come back to me when you are using json to encode an entire document" How is that relevant to the article, which is about COS? In other words, what does COS lack what XML has?

* Infrastructure (schema support - DTD, Schema, RelaxNG; transformation - XSLT) * No obvious document format (What encoding are the strings? How to escape characters? * Only used to describe predefined object types (boolean, strings, arrays, dictionaries * Hard to ensure the integrity of the data without interpreting the data from the interpreter itself (no external validation)

You know this can be done on top when you have demand for this? I prefer a non-bloated protocol format over XML anytime. How often does the DTD not matter at all ? How often is the encoding fixed by convention ? ...

Re: In Defense of COS, or Why I Love JSON and Hate XML

#32

Post by mcantelon »

pippy wrote: post #30
randomfool wrote: post #4

Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.

Explicit is better than implicit. If you have to explain something you've probably written the JSON wrong. You can always do this: { 'people' : 10, 'desc': 'People who will attend' }

>Explicit is better than implicit.

Which is why not intermingling comments with data makes sense.

>If you have to explain something you've probably written the JSON wrong.

You could say the same about code: "if you need to comment then your code isn't clear enough". In reality sometimes commenting code or data is helpful.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#33

Post by thristian »

DougWebb wrote: post #15

XML can do the same trick with indirect objects as COS, using ID and IDREF type attributes. A number of years ago I was dealing with the archival and retrieval/display of enormous medical textbooks in XML, and I couldn't efficiently pull out arbitrary elements (chapters, sections, paragraphs, etc) because of the hierarchical nature of the XML document structure. I had to parse the whole thing to use an XPATH to get t…

ID/IDREF isn't exactly the same as indirect objects in COS. When you're parsing an XML document, ID/IDREF are just attributes like any other that get added to the DOM, and then application code can dereference them later if it wants. In COS, indirect objects are part of the serialisation format and the parser needs to understand them and dereference them in order to be able to parse the file.

For example, the COS "stream" object type is serialised as a settings dictionary, followed by the 'stream' keyword, the stream data, and the 'endstream' keyword. But what happens when the stream happens to contain the bytes 'endstream'? Well, the settings dictionary has a "Length" key that tells you how long the stream is, without you having to scan for the 'endstream' keyword. However, because most streams are compressed and compression makes it difficult to guess in advance exactly what the compressed size willl be, COS allows you to make the Length key an indirect reference to an integer defined later in the file. Like so:

    >
    stream
    ...compressed data goes here...
    endstream
    % And now we define object 42 revision 0
    42 0 obj
    12345
    endobj
So, the parser needs to know the length of the compressed stream in order to parse it, but it needs to have parsed the compressed stream in order to get to the length data. The way out of this catch-22 is the object index at the end of the file, which gives you the index and location of each indirect object. A COS parser needs to start at the end of the file and load all the indirect objects, cache them, then go back to the beginning and stitch them into the deserialised object graph as they're referenced.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#34

Post by chipsy »

joe_the_user wrote: post #27
ishbits wrote: post #17

Earlier quoted context omitted.

YAML is better suited for configuration files.

Yaml is not good for configuration files because it is not easily human-editable. It seems "easy" but meaningful whitespace is a cluster-f ck . Edit: I have been looking for reasonable configuration file formats for a while. Json actually has pretty bad human-readability at any scale because of its quoted key-values. Yaml is easily readable but when a user tries to change anything, things go to hell. The humble ini-f…

I rolled my own format specifically for configuration. No significant whitespace, delimiters may dangle, and the parser implementation can be configured to accept very high ambiguity(including, if desired, mixtures of sequence and key-value data).

https://github.com/triplefox/triad/blob/master/dev/com/ludam...

A "real-world" example https://github.com/triplefox/triad/blob/master/examples/Asse...

Re: In Defense of COS, or Why I Love JSON and Hate XML

#35

Post by pom »

Like many, I feel that the poster is throwing the baby with the bathwater. Yes, SOAP and XML Schema are horrible. Don't use them, then. Yes, XML is verbose, but that's exactly why Relax NG has a compact syntax. Use that if you don't like the XML syntax. Yes, data can be expressed as attributes or elements, but there are simple rules of thumb to decide between one or the other: if your data can have structure, or you may want to have multiple instances of the same thing, it's generally better to use an element; otherwise an attribute should do the trick.

There are also errors and approximations: XML did not introduce the bracket syntax, it inherited it from SGML. A DTD is not a schema (and if you want to criticize XML, you should point out that it should not have inherited DTDs from SGML.) He doesn't even mention the worst part about comments, which is that you can't have -- inside a comment (very annoying when commenting a large block of data...)

XML has many beautiful applications, like SVG, SMIL (which never took off but keeps getting rediscovered/reimplemented in an inconsistent manner [full disclosure: I participated in the SMIL and CDF W3C working groups]), XSLT, &c. XHTML was not perfect by a long stretch but the new HTML5 syntax is much, much worse.

Use XML, JSON, and whatever is necessary to get the job done. For the project that I am working on right now, I am using XML for serializing Web app descriptions; in this situation, XML is clearly better than JSON.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#36

Post by thristian »

xrt wrote: post #8

How is COS separate from PostScript? It looks like a straight PS dictionary.

Well, PostScript probably doesn't have the indirect-object-reference index at the end, but I don't really know much about PostScript so I couldn't say for sure.

I wonder if PostScript is to COS as JavaScript is to JSON.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#37

Post by jscn »

joe_the_user wrote: post #27
ishbits wrote: post #17

Earlier quoted context omitted.

YAML is better suited for configuration files.

Yaml is not good for configuration files because it is not easily human-editable. It seems "easy" but meaningful whitespace is a cluster-f ck . Edit: I have been looking for reasonable configuration file formats for a while. Json actually has pretty bad human-readability at any scale because of its quoted key-values. Yaml is easily readable but when a user tries to change anything, things go to hell. The humble ini-f…

  It seems "easy" but meaningful whitespace is a cluster-fck.
Tell that to everyone using Python. If your editor can't handle meaningful whitespace transparently, it sounds like you need a better editor.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#38

Post by angersock »

TazeTSchnitzel wrote: post #26
masklinn wrote: post #11

Earlier quoted context omitted.

On the other hand, comments were explicitly excluded from JSON by Crockford (with the thinking — probably correct — that they'd be abused to embed such things as parsing directives or other out-of-band content)

I believe he was correct at the time, he removed them once people started using them for parsing directives. (JSON hasn't always been frozen)

Having seen/used the rudimentary commenting mechanism in Wavefront .OBJ files (a 3D interchange format) to stuff in more modern information (tangents, additional UV channels, etc. etc.), I can say that comments can help a format live on well past its expiry date.

That said, I will not pretend for a second that this is a good idea. Crockford did the right thing.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#39

Post by rdtsc »

randomfool wrote: post #4

Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.

JSON not having comments is a deliberate design decision (a feature if you want). The reason is if it supported comments, they would have ended up being used to for meta languages and parse directives that would have created JSON documents that could not be parsed or processed by all JSON parsers -- it would have fragmented the JSON ecosystem quite a bit. So it might seem like an accidental bug or omission but it is not it is on purpose and I agree with it.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#40

Post by sigzero »

jscn wrote: post #37
joe_the_user wrote: post #27

Earlier quoted context omitted.

Yaml is not good for configuration files because it is not easily human-editable. It seems "easy" but meaningful whitespace is a cluster-f ck . Edit: I have been looking for reasonable configuration file formats for a while. Json actually has pretty bad human-readability at any scale because of its quoted key-values. Yaml is easily readable but when a user tries to change anything, things go to hell. The humble ini-f…

It seems "easy" but meaningful whitespace is a cluster-fck. Tell that to everyone using Python. If your editor can't handle meaningful whitespace transparently, it sounds like you need a better editor.

Python is a programming language. Worlds of difference there.
Post reply on HN