3 ms·

I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data t

by gen220 4y ago

I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.

falcolas 4y ago
> I think people dislike XML precisely because it's so flexible and unopinionated. You're probably right. > Basically, it's easy to "hold it wrong" in a way that harms consumers. I feel a bit like this could equally apply to things like GraphQL. I spend more time reading the docs on how someone's internal data model is built than I do writing GraphQL queries. And if I get that data model slightly wrong, my query's garbage. But that's probably a separate, vendor specific (coughnewrelic), rant.
- gen220 4y ago
  Every "contract" language (e.g. .graphql) I've used so far has it's ups and downs. One that keeps biting us in GQL, for instance, is that it won't let you define a union type for mutation inputs, so you end up needing N methods like `GetByX(X)`, `GetByY(Y)`, `...` instead of a single `Get(X|Y|...)`. Not to mention support for versioning message types, etc... FWIW: I think proto3 is probably the best I've used, at length and in production. Granted it has its "warts", but the idioms to circumvent them are fairly well-documented and agreed upon, even if they're a bit "ugly" in the syntactical sense. FWIW pt 2: Like yourself, I think, I would not consider JSON to be appropriate as a schema-defining "contract" language in 2022, for a company that plans to be around in 5 years. There are too many better options available.
- solarkraft 4y ago
  Over-engineering (relative to the complexity of the task you want to solve). Enterprise solutions are often so complex and generic that they can theoretically do and interoperate with anything, but are also hard to get started with and use well. People like to start with simple things and expand from there instead of buying a whole house when they just want a sink (am I using the phrase right?). In my opinion this makes a lot of because it avoids unnecessary complexity and sensitizes people to why some complexity is in fact necessary.
mind-blight 4y ago
I think it also got horribly abused by some use cases. People tried to allow programming in it (e.g. if statements and loops) when an actual DSL would have been a better solution. I know that was my last straw before I started assuming that anything that required XML would be painful to work with. It wasn't an entirely fair assumption, but it was correct often enough that I used it as a helpful heuristic.
lenkite 4y ago
A schema can be written in 15-30 mins to make XML as opinionated as you want it to be.
- adgjlsfhk1 4y ago
  and then you'll read an xml file that doesn't meet your schema and your code will crash
  - lenkite 4y ago
    With nice validation errors pointing to line, col where unexpected information was found. I'll definitely take that.
  - delta_p_delta_x 4y ago
    That's the point of the schema—use it to generate compliant serialisation/deserialisation code, and use that code to generate/read your schema-compliant XML. No issues anywhere. There's only one point of failure here: bugs in the code generator.
- Spivak 4y ago
  I think the other smell is not using serializers with XML. If when you consume a document you’re not getting an actual useful object back of course you’re going to hate it.

by gen220 4y ago

falcolas 4y ago

> I think people dislike XML precisely because it's so flexible and unopinionated. You're probably right. > Basically, it's easy to "hold it wrong" in a way that harms consumers. I feel a bit like this could equally apply to things like GraphQL. I spend more time reading the docs on how someone's internal data model is built than I do writing GraphQL queries. And if I get that data model slightly wrong, my query's garbage. But that's probably a separate, vendor specific (coughnewrelic), rant.

gen220 4y ago
Every "contract" language (e.g. .graphql) I've used so far has it's ups and downs. One that keeps biting us in GQL, for instance, is that it won't let you define a union type for mutation inputs, so you end up needing N methods like `GetByX(X)`, `GetByY(Y)`, `...` instead of a single `Get(X|Y|...)`. Not to mention support for versioning message types, etc... FWIW: I think proto3 is probably the best I've used, at length and in production. Granted it has its "warts", but the idioms to circumvent them are fairly well-documented and agreed upon, even if they're a bit "ugly" in the syntactical sense. FWIW pt 2: Like yourself, I think, I would not consider JSON to be appropriate as a schema-defining "contract" language in 2022, for a company that plans to be around in 5 years. There are too many better options available.
solarkraft 4y ago
Over-engineering (relative to the complexity of the task you want to solve). Enterprise solutions are often so complex and generic that they can theoretically do and interoperate with anything, but are also hard to get started with and use well. People like to start with simple things and expand from there instead of buying a whole house when they just want a sink (am I using the phrase right?). In my opinion this makes a lot of because it avoids unnecessary complexity and sensitizes people to why some complexity is in fact necessary.

mind-blight 4y ago

I think it also got horribly abused by some use cases. People tried to allow programming in it (e.g. if statements and loops) when an actual DSL would have been a better solution. I know that was my last straw before I started assuming that anything that required XML would be painful to work with. It wasn't an entirely fair assumption, but it was correct often enough that I used it as a helpful heuristic.

lenkite 4y ago

A schema can be written in 15-30 mins to make XML as opinionated as you want it to be.

adgjlsfhk1 4y ago
and then you'll read an xml file that doesn't meet your schema and your code will crash
- lenkite 4y ago
  With nice validation errors pointing to line, col where unexpected information was found. I'll definitely take that.
- delta_p_delta_x 4y ago
  That's the point of the schema—use it to generate compliant serialisation/deserialisation code, and use that code to generate/read your schema-compliant XML. No issues anywhere. There's only one point of failure here: bugs in the code generator.
Spivak 4y ago
I think the other smell is not using serializers with XML. If when you consume a document you’re not getting an actual useful object back of course you’re going to hate it.