4 ms·
When do you put something in an attribute and when do you give it its own tag? What if semantically it belongs in an attribute but the kind of complicated parsi
by stormbrew 5y ago
When do you put something in an attribute and when do you give it its own tag? What if semantically it belongs in an attribute but the kind of complicated parsing rules make putting it there cumbersome? Should you use <![CDATA[]]> or base64 to encode non-xml data? If you use CDATA what if the data has a ]]>? If you use tags for hierarchical information, what do you do if there happens to be some random non-whitespace/comment data between the tags as if it was html?
I don't really like interacting with json as a human user (mostly because restricting trailing commas and comments are both utterly awful design choices), but I'd take it a hundred times over the enormous ball of complexity and decision paralysis that xml imposes on you. There's just too much there there.
- dorfsmay 5y agoAgreed. I wish json5 had become, or becomes the standard. https://json5.org/ https://json5.org/
- djur 5y agoOne of the virtues of JSON is that you can break it into parseable chunks by line, which also enables stuff like line-delimited JSON streams. JSON5 seems like a good format for a configuration file, though.
- j1elo 5y agoThe problem with JSON alternatives is that now I come to say that I wish HJSON [0] had become or becomes the standard... so now we have the N+1 Standards xkcd comic strip again [0]: https://hjson.github.io/faq.html https://hjson.github.io/faq.html
- zvrba 5y ago> When do you put something in an attribute and when do you give it its own tag? [...] Oh, the same old red herrings around irrelevant details. The simplest answer is: it doesn't matter. Let your serializer of choice handle it. More in-depth answer: depends on what your schema tools and serializers support best. For example, I define my classes in C# and use dot net's built-in schema exporter to generate schemas (which in turn get compiled again into strongly-typed classes for other languages, e.g., Java). I chose DataContractSerializer, and its rules are simple: "user" data belongs to elements, serializer metadata belongs to attributes. Which makes sense because arbitrary attributes can appear on elements without breaking the schema (e.g., DCS uses xsi:type attribute for polymorphic deserialization). It also decides for you to use base64 for binary data. Bottom line: use tooling and don't try to tweak the details of the XML form.
- rcxdude 5y agoOK, but this approach is totally useless when it comes to a public API, which is the topic of this thread. Especially when it comes to backward compatibility.
- zvrba 5y ago1) If _you_ are designing a new API, then my answer still holds. Choose a serializer and let it decide the wire format for you. 2) If someone else has already published the API, well, then it's already decided. In both cases, your objections are moot.
- GoblinSlayer 5y agoThe topic is about decision problems, not about backward compatibility. That said, JSON has corner cases too, similar to XML or worse. All those complaints are just rationalization of hipster propaganda.
- Spivak 5y agoJSON has corner cases but the advantage is that every JSON document has a single obvious mapping to language primitives — dicts, lists, strings, floats. Nobody has to agree beforehand how to load JSON data. In contrast the generic mapping for XML is a Tree[str (name), Dict[str, str] (attrs), Union[str, Tree] (body)] which maps so poorly between languages that people do one of two things — implement formats on top of XML to do serialization which leads to non-interoperability when different software does it differently, or parse to a database-like “Abstract XML object that you query with xpath.
- dwaite 5y agoPosted in a comment above, but the idea is that text content is text content, because XML was intended as a document interchange format, not a data interchange format. When you look at SVG content for instance, you'll notice colors and coordinates are contained within attributes, because it means a document reader which cannot understand some crazy new drawing element would still interpret that data is text content, leaving the document accessible (if perhaps badly formatted). If you care about that rule, then structured, semantic, non-user-accessible data uses elements for structure and attributes for data. This also lets you ignore the difference between semantic and non-semantic whitespace - no whitespace has semantics. CDATA sections are (usually) represented in tooling, but should be considered just a text node with different escaping rules (unless your document format actually assigns a purpose, which is a really bad idea from an interoperability perspective). CDATA is not meant to provide a way to embed binary data (both XML and JSON are somewhat bad for information which is not primarily text). Similarly, processing instructions are somewhat orthogonal to the document format. I believe XSLT is the only spec which defined a standard behavior for them, but there were examples such as commercial document editors which saved information like the cursor position as processing instructions. FWIW (as a human interacting with JSON) - there are extensions to JSON such as JSON5 which aim to add the extra flexibility that makes data entry easier. JSON5 adds comments, trailing commas, unquoted symbols, single quoted strings, and so on. Perhaps its biggest issue is that it allows non-finite number values like NaN, which makes it a superset of JSON at the data model layer. So you can't be guaranteed JSON5 text can be stripped and quoted into valid JSON text.