Live data from Hacker News

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

hsivonen.fi

251–255 of 255 posts

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

#251
post #174
post #148

Earlier quoted context omitted.

> JSON (assuming everyone knows what this is) The new .net uses json, it's awful. No comments allowed and it get's pretty unreadable when you have nested configuration elements.

I seriously think the lack of comments is a deal breaker for JSON config files for me. At least with what I'm doing now. I find myself changing configs a ton, and I love being able to simply change which blocks are commented to get what I want, without having to dig anywhere.

I agree...and I found a Gulp plugin that lets me pre-strip comments from my JSON files as part of the build process.

So I use JSON-with-comments, but the app only sees the stripped files.

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

#252
post #220

Earlier quoted context omitted.

>In those cases, I would rather have XML config files than undocumented binary blobs as config files. False dichotomy. Better than XML and binary blobs: * JSON (assuming everyone knows what this is) * YAML [0] * Lua tables (if you're already using Lua as a scripting language; Lua started out as a configuration language after all) * INF format [1] (not my favorite, but pretty easy to parse and much better for humans t…

I am missing a config file format / parser&generator lib that preserves every comment and format (empty lines, etc.) after a read/write cycle.

I've written that for Lua files. And I've seen it for XML, to be fair.

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

#253
post #237

Earlier quoted context omitted.

> The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be inside the content tag. In this specific case, maybe – but generally, it is not true that you can infer the namespace of an element from context. Also, elements can have multiple attributes with di…

> It is very useful to embed any arbitrary language, as XML processors can preserve the content they do not understand without processing it. My XSLT stylesheet would have no issue with SVG embedded in XHTML, just as your web browser most likely ignores everything about the SVG linked above it can not understand. Sure, but you can ignore extra attributes in JSON or hypothetical XML-without-namespacing too. I feel lik…

Ignoring other attributes in data formats without namespaces is not as easy. What if one language is embedded in another and each one has a title element?

I do not know why you “feel” that way about the middle you want to exclude. It has been proven to be very useful in practice for me. Also without it, XML would not have the “extensible” property.

The way you describe working with “XHTML-with-embedded-SVG” reads to me like there is something about namespaces or your toolchain that you have difficulties with. I found that with XML-based systems, especially XSLT, it is easy to make a task needlessly complicated if one does not understand the details.

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

#254
post #235

Earlier quoted context omitted.

You may have incomplete documents (e.g. documents with conditional sections, very much like XSLT): Here you'll first process your code part an copy the contents as they are and then process the contents; but in the source document the two languages are interspersed. Or you may want to extend your text format with, say, literate programming and add code fragments and files. In my homegrown system it's like that: ... .…

OK, I guess that takes things a level up. I don't like that kind of interspersed style and I don't think incomplete documents should be the same kind of thing as complete ones (e.g. one can't meaningfully validate your first example, because what if the "whatever" is an element that has to be present exactly once). But I can see that if you want to write things this way then namespaces help.

“I don't like” seems to be an æsthetic argument, not a technical one.

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

#255
post #110

My "favorite" XML formats are the one that are just some kind of weird meta-format and don't really use any of the XML features: blah blah this is the attribute value ... And yes, these types of abominations are everywhere. The only way to avoid being called a Bozo when producing XML is to either a) ensure that humans never had to see this craziness b) don't use XML XML as a config file format, in particular, is prob…

I'm sure you will also love JSONx: http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com....

Well, if you have to store arbitrary, opaque JS object in XML document, it is much better way than JSON in CDATA
Post reply on HN