9 ms·

> 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 a

by 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 ago
OK, 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 ago
  1) 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 ago
  The 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 ago
    JSON 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.
    - GoblinSlayer 5y ago
      JSON maps well to javascript types, but not anything else. And float isn't an obvious mapping: the standard does have a concept of an integer number, and most numbers are indeed integers. Arrays do everything objects do, but have better performance and better defined behavior. >Nobody has to agree beforehand how to load JSON data. Such agreement is never necessary, it's up to the programmer what to write, and the standard doesn't specify behavior of JSON parsers anyway, it only defines JSON documents. For example there's no need to use hashtables, it's a random javascript artifact due to parsing JSON with the eval function. >when different software does it differently I assume you mean schemaless documents here. Those are always abstract databases, both XML and JSON. I suppose there's jq that can query abstract JSON databases.
      - Spivak 5y ago
        > JSON maps well to JavaScript types, but not anything else. I grant you that JSON might be equally as awkward as XML languages like C but pretty much every language -- Python, Ruby, Java have very sane mappings to and from JSON types. You don't ever really have to "query" a JSON object, you just `json.loads` and `for item in obj["key"]:`. Even in the cases with schemas you're still usually only working with primitive types. > Such agreement is never necessary, it's up to the programmer what to write... What I mean is that there's not weirdness like having to encode types in the base document. You don't have to do things like <blahblah type="dict"> <item> <key>dlkj</key> <value>kjdf</value> </item> <blahblah> where different projects / parsers might do it differently. The "abstract JSON types" are actually useful and expressive where in XML everyone has to carve out their own way to represent lists, mappings, and numbers out of trees because basically nobody works with just trees in day-to-day work. I think we might be talking about two different use-cases. If what you want to do with XML / JSON is serialize arbitrary classes in $specific_language and then read it back then nothing really matters; the on-disk format is just an implementation detail. But abstract JSON works really really well as a schema everyone agrees on and supported by every language.
  - stormbrew 5y ago
    > That said, JSON has corner cases too, similar to XML or worse. Feel free to list some.
    - zvrba 5y ago
      https://bishopfox.com/blog/json-interoperability-vulnerabilities https://bishopfox.com/blog/json-interoperability-vulnerabili...
      - deleted 5y ago
        [deleted]
      - stormbrew 5y ago
        Most of these just amount to "some parsers are bad", which.. I mean sure? But xml's surface area for parsers to be 'bad' is so much greater, and its gotchas are thus much more subtle. I hope you're not trying to suggest that all xml parsers are identical and perfect. Your assertion was that json's edge cases are "as bad or a little worse" but imo this document doesn't suggest that at all. Every single thing listed in it can go more wrong with xml, not less.
    - GoblinSlayer 5y ago
      The often mentioned design paralysis of choice between elements and attributes - in JSON there can be many ways to implement a collection of name/value pairs. One interesting case is compound key: you can use a mini serialization format and still make it an object (actually saw this in the wild).
      - wusspuss 5y ago
        > in JSON there can be many ways to implement a collection of name/value pairs. Are there? JSON has dicts and lists. I mean you could store a collection of name value pairs in a list, maybe even a list of lists, but that's just stupid and an incorrect usage of the format. Where as in xml there really are tons of ways to do that, and ALL of them are awkward
nextaccountic 5y ago
This just don't work for interoperable protocols (or file formats). If you have a protocol with multiple implementations, they may be written in different languages, with different XML libraries.
- zvrba 5y ago
  The serializer exports the schema and you map the schema to whatever code is needed, using whatever XML library, to extract the data based on the schema. XML rules are strict and how to extract data from the document, given schema, is unambiguous. If you don't have a decent XML library, then you're stuck. Oh wait, the same holds for HTML any other format.
timetop494 5y ago
>The simplest answer is: it doesn't matter. Let your serializer of choice handle it. Except, this absolutely matters! I've had serializer incompatibilities across platforms on both things like json and much simpler binary formats. Letting the "serializer handle it" falls apart in reality, especially on extremely complicated formats like XML. The only reliable way to make complicated cross platform de/serializing work is to define a feature subset and adhere to that.
stormbrew 5y ago
This is really not a simple answer. Now you've just compounded the problem with N solutions, where N is the number of encoders in the wild in use by people who want to talk to your service. And then you've basically got SOAP, which is one of those acronyms that manages to be none of its constituent words in practice.

by zvrba 5y ago

rcxdude 5y ago

OK, 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 ago
1) 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 ago
The 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 ago
  JSON 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.
  - GoblinSlayer 5y ago
    JSON maps well to javascript types, but not anything else. And float isn't an obvious mapping: the standard does have a concept of an integer number, and most numbers are indeed integers. Arrays do everything objects do, but have better performance and better defined behavior. >Nobody has to agree beforehand how to load JSON data. Such agreement is never necessary, it's up to the programmer what to write, and the standard doesn't specify behavior of JSON parsers anyway, it only defines JSON documents. For example there's no need to use hashtables, it's a random javascript artifact due to parsing JSON with the eval function. >when different software does it differently I assume you mean schemaless documents here. Those are always abstract databases, both XML and JSON. I suppose there's jq that can query abstract JSON databases.
    - Spivak 5y ago
      > JSON maps well to JavaScript types, but not anything else. I grant you that JSON might be equally as awkward as XML languages like C but pretty much every language -- Python, Ruby, Java have very sane mappings to and from JSON types. You don't ever really have to "query" a JSON object, you just `json.loads` and `for item in obj["key"]:`. Even in the cases with schemas you're still usually only working with primitive types. > Such agreement is never necessary, it's up to the programmer what to write... What I mean is that there's not weirdness like having to encode types in the base document. You don't have to do things like <blahblah type="dict"> <item> <key>dlkj</key> <value>kjdf</value> </item> <blahblah> where different projects / parsers might do it differently. The "abstract JSON types" are actually useful and expressive where in XML everyone has to carve out their own way to represent lists, mappings, and numbers out of trees because basically nobody works with just trees in day-to-day work. I think we might be talking about two different use-cases. If what you want to do with XML / JSON is serialize arbitrary classes in $specific_language and then read it back then nothing really matters; the on-disk format is just an implementation detail. But abstract JSON works really really well as a schema everyone agrees on and supported by every language.
- stormbrew 5y ago
  > That said, JSON has corner cases too, similar to XML or worse. Feel free to list some.
  - zvrba 5y ago
    https://bishopfox.com/blog/json-interoperability-vulnerabilities https://bishopfox.com/blog/json-interoperability-vulnerabili...
    - deleted 5y ago
      [deleted]
    - stormbrew 5y ago
      Most of these just amount to "some parsers are bad", which.. I mean sure? But xml's surface area for parsers to be 'bad' is so much greater, and its gotchas are thus much more subtle. I hope you're not trying to suggest that all xml parsers are identical and perfect. Your assertion was that json's edge cases are "as bad or a little worse" but imo this document doesn't suggest that at all. Every single thing listed in it can go more wrong with xml, not less.
  - GoblinSlayer 5y ago
    The often mentioned design paralysis of choice between elements and attributes - in JSON there can be many ways to implement a collection of name/value pairs. One interesting case is compound key: you can use a mini serialization format and still make it an object (actually saw this in the wild).
    - wusspuss 5y ago
      > in JSON there can be many ways to implement a collection of name/value pairs. Are there? JSON has dicts and lists. I mean you could store a collection of name value pairs in a list, maybe even a list of lists, but that's just stupid and an incorrect usage of the format. Where as in xml there really are tons of ways to do that, and ALL of them are awkward

nextaccountic 5y ago

This just don't work for interoperable protocols (or file formats). If you have a protocol with multiple implementations, they may be written in different languages, with different XML libraries.

zvrba 5y ago
The serializer exports the schema and you map the schema to whatever code is needed, using whatever XML library, to extract the data based on the schema. XML rules are strict and how to extract data from the document, given schema, is unambiguous. If you don't have a decent XML library, then you're stuck. Oh wait, the same holds for HTML any other format.

timetop494 5y ago

>The simplest answer is: it doesn't matter. Let your serializer of choice handle it. Except, this absolutely matters! I've had serializer incompatibilities across platforms on both things like json and much simpler binary formats. Letting the "serializer handle it" falls apart in reality, especially on extremely complicated formats like XML. The only reliable way to make complicated cross platform de/serializing work is to define a feature subset and adhere to that.

stormbrew 5y ago

This is really not a simple answer. Now you've just compounded the problem with N solutions, where N is the number of encoders in the wild in use by people who want to talk to your service. And then you've basically got SOAP, which is one of those acronyms that manages to be none of its constituent words in practice.