4 ms·

The best part about csv, anyone can write a parser in 30 minutes meaning that I can take data from the early '90s and import it into a modern web service. The

The best part about csv, anyone can write a parser in 30 minutes meaning that I can take data from the early '90s and import it into a modern web service. The worst part about CSV, anyone can ride a parser in about 30 minutes, meaning that it's very easy to get incorrect implementations, incorrect data, and other strange undefined behaviors. But to be clear json, and yaml also have issues with everyone trying to reinvent the wheel constantly. XML is rather ugly, but it seems to be the most resilient.

Xelbair 2y ago
until you find someone abusing XSD schemas, or someone designing a "dynamically typed" XML... or sneaks in extra data in comments - happened to me way often than it should.
- 999900000999 2y ago
  My condolences. Any open standard runs the risk of this happening. It's not a problem I think we'll ever solve.
  - marcosdumay 2y ago
    In principle, if you make your standard extensible enough, people should stop sneaking data into comments or strings. ... What makes the GP's problem so much more amusing. XML was the last place I'd expect to see it.
    - 999900000999 2y ago
      That's assuming they know how to use it properly. Rest has this same issue. I've seen this when trying to integrate with 3rd party apis. Status Code 200 Body: Sorry bro, no data. Even then, this is subject to debate. Should a 404 only be used when the endpoint doesn't exist ? When we have no data to return, etc.
      - Xelbair 2y ago
        i think that default REST is a bit problematic as it conflates transport protocol level errors with application logic ones. At least unless you use application/problem+json or application/problem+xml MIME types but those are still just in draft stage https://datatracker.ietf.org/doc/html/rfc9457#name-the-problem-details-json-ob https://datatracker.ietf.org/doc/html/rfc9457#name-the-probl...
- MathMonkeyMan 2y ago
  You know what grinds my gears about using XSD for message definitions? Namespaces. Namespaces are a good idea and were done well in XML, as far as I can see, but with XSD you run into this [problem][1]: Namespaces are used to qualify tags and attributes in XML elements. But they're also used by XSD to qualify the names of types defined in the schema. A sequence element's type is indicated by the value of its "type" attribute. The attribute value is a string that is the namespace-qualified name of the type. So, if you want to change the alias of an XML namespace in an XSD schema, you can't just use your XML library's facilities for namespace management. You also have to go find the "type" attributes (but not all of the "type" attributes), parse their values, and do the corresponding alias change in the type name. Don't use a string for a thing that is not a string! I guess in XML attributes you have no choice. XAML improved on the situation a bit. [1]: https://github.com/dgoffredo/stag/tree/master/src/stag/xsd-util https://github.com/dgoffredo/stag/tree/master/src/stag/xsd-u...
a3w 2y ago
For some side projects, I would like use XML, but cannot read the spec, as that costs money. So I cannot trust XML in depth, and depend on using a library that bought the spec and hopefully adheres to it.

Xelbair 2y ago

until you find someone abusing XSD schemas, or someone designing a "dynamically typed" XML... or sneaks in extra data in comments - happened to me way often than it should.

999900000999 2y ago
My condolences. Any open standard runs the risk of this happening. It's not a problem I think we'll ever solve.
- marcosdumay 2y ago
  In principle, if you make your standard extensible enough, people should stop sneaking data into comments or strings. ... What makes the GP's problem so much more amusing. XML was the last place I'd expect to see it.
  - 999900000999 2y ago
    That's assuming they know how to use it properly. Rest has this same issue. I've seen this when trying to integrate with 3rd party apis. Status Code 200 Body: Sorry bro, no data. Even then, this is subject to debate. Should a 404 only be used when the endpoint doesn't exist ? When we have no data to return, etc.
    - Xelbair 2y ago
      i think that default REST is a bit problematic as it conflates transport protocol level errors with application logic ones. At least unless you use application/problem+json or application/problem+xml MIME types but those are still just in draft stage https://datatracker.ietf.org/doc/html/rfc9457#name-the-problem-details-json-ob https://datatracker.ietf.org/doc/html/rfc9457#name-the-probl...
MathMonkeyMan 2y ago
You know what grinds my gears about using XSD for message definitions? Namespaces. Namespaces are a good idea and were done well in XML, as far as I can see, but with XSD you run into this [problem][1]: Namespaces are used to qualify tags and attributes in XML elements. But they're also used by XSD to qualify the names of types defined in the schema. A sequence element's type is indicated by the value of its "type" attribute. The attribute value is a string that is the namespace-qualified name of the type. So, if you want to change the alias of an XML namespace in an XSD schema, you can't just use your XML library's facilities for namespace management. You also have to go find the "type" attributes (but not all of the "type" attributes), parse their values, and do the corresponding alias change in the type name. Don't use a string for a thing that is not a string! I guess in XML attributes you have no choice. XAML improved on the situation a bit. [1]: https://github.com/dgoffredo/stag/tree/master/src/stag/xsd-util https://github.com/dgoffredo/stag/tree/master/src/stag/xsd-u...

a3w 2y ago

For some side projects, I would like use XML, but cannot read the spec, as that costs money. So I cannot trust XML in depth, and depend on using a library that bought the spec and hopefully adheres to it.