6 ms·

XML is a actually wonderful format for data and especially extensible configuration if you combine it with XML Schema and CSS selectors... - XML schemas give y

XML is a actually wonderful format for data and especially extensible configuration if you combine it with XML Schema and CSS selectors... - XML schemas give you a ready-to-use format to describe, restrict and document available configuration settings. The unique keys help and a libxml2 gives ready to use validation, even if you may need to 'translate' its error messages before showing them to end users - XML schemas also support other annotations so you can further generalise your configuration readers by recording the necessary bindings in the XML schema itself, allowing to use it eg to define application user interfaces. - Almost any text editor can do basic syntax validation preventing most typographic errors, and even better if they can read the schema - XML schemas are extensible using <import>s, but namespaces still enforce some separation. You can define explicit points where plugins extend your configuration format using <any> - Human editable - closing tags are noisy but more readable than }],{}] when non-programmers may have to edit these files just to add a few extra textfields to an UI. - Better datatype support, eg datetimes, by using XML schemas. JSON's type support is too limited - Support for comments! - And once you've verified the schema... CSS selectors and DOM APIs to actually process the XML documents. YAML fixed quite a few things, but still no date times or as far as I know standardised approaches to defining schemas. And I've lost count at how any attempts exist to add schema information or namespacing to JSON... But for markup... we may be better off to just use markdown inside CDATA blocks

sedachv 7y ago
> XML schemas give you a ready-to-use format to describe, restrict and document available configuration settings. As someone that likes and uses s-expressions, I never thought I would find myself defending XML, but here we are in 2019, no one understands basic parsing theory anymore, and file formats have "evolved" to hot garbage like YAML and TOML. XML has some great tools in comparison: http://xmlsoft.org/xmllint.html http://xmlsoft.org/xmllint.html https://relaxng.org/ https://relaxng.org/ > But for markup... we may be better off to just use markdown inside CDATA blocks SGML can still make a comeback: https://leancrew.com/all-this/2014/09/sgml-nostalgia/ https://leancrew.com/all-this/2014/09/sgml-nostalgia/
- novok 7y ago
  YAML and TOML were optimized for human reading and writing, like markdown. XML & even JSON are not as human optimized, but still human usable.
  - sedachv 7y ago
    > YAML and TOML were optimized for human reading and writing, like markdown. That was the rationalization, in reality I don't know what actual writing use case they were optimized for (Notepad?). XML in a syntax-aware editor with the help of automatic schema validation makes it far easier to write than YAML or TOML.
    - novok 7y ago
      I don't need a special editor to write out YAML (if it didn't have tab dependence) or TOML quickly. It's also a lot faster for a human to read vs XML. JSON is fairly readable, but a bit of a pain to write out compared to ini files, since you have to quote all strings. If your going into complicated things like schemas or other complicated structures, then you probably shouldn't be using YAML or TOML. I would mostly use it for config or other simple things. At this point if you are not interacting with 20 year old java software, that was created when JSON didn't exist and XML was king, you should be using TOML for simple config, JSON for most things and heavyweight XML, protobuf or csv for the specialized cases. And while we are at it, markdown for simple documentation. Even gradle decided to use groovy scripts as their config language because it's far more human readable and usable.
      - sedachv 7y ago
        > At this point if you are not interacting with 20 year old java software, that was created when JSON didn't exist and XML was king, you should be using TOML for simple config, JSON for most things and heavyweight XML, protobuf or csv for the specialized cases. You should be using S-expressions.
  - gambler 7y ago
scott_s 7y ago
I agree. The author and other commenters here have not proposed an alternative which provides two features I consider critical to a generic data format: schema specification and validation; and easy parsing support in many ecosystems. JSON and Yaml don't seem to have mature, widely adopted schema specification and validation. And I'm not aware of anything outside of XML, JSON and Yaml which have such wide parsing support in so many different ecosystems.
- theamk 7y ago
  JsonSchema is pretty good -- it is not as widely used as XSD, but it has libraries for most languages. And of course JSON is the easiest thing to parse in scripting languages, like Python and Ruby -- the entire API is one line, and then you have a native structure you can work with.
  - spiralx 7y ago
    > JsonSchema is pretty good -- it is not as widely used as XSD, but it has libraries for most languages. It's okay now that the newest revisions support more realistic use cases, but ironically I find it impossible to write as JSON... I write them as YAML which my validator supports natively :) It's still not as nice as RELAX-NG's compact schema format though IMO :) https://relaxng.org/compact-tutorial-20030326.html https://relaxng.org/compact-tutorial-20030326.html And the LXML library for Python was a pleasure to use compared to any other similar library I've used.
tannhaeuser 7y ago
> But for markup... we may be better off to just use markdown inside CDATA blocks No we arent't. markdown itself is literally specified as a shortform of HTML [1], and can be translated into canonical angle-bracket syntax using SGML short references (though not completely eg. markdown reference links require unlimited forward lookup). This gives a canonical representation of markdown in SGML/XML even if you don't use SGML. [1]: https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/

sedachv 7y ago

> XML schemas give you a ready-to-use format to describe, restrict and document available configuration settings. As someone that likes and uses s-expressions, I never thought I would find myself defending XML, but here we are in 2019, no one understands basic parsing theory anymore, and file formats have "evolved" to hot garbage like YAML and TOML. XML has some great tools in comparison: http://xmlsoft.org/xmllint.html http://xmlsoft.org/xmllint.html https://relaxng.org/ https://relaxng.org/ > But for markup... we may be better off to just use markdown inside CDATA blocks SGML can still make a comeback: https://leancrew.com/all-this/2014/09/sgml-nostalgia/ https://leancrew.com/all-this/2014/09/sgml-nostalgia/

novok 7y ago
YAML and TOML were optimized for human reading and writing, like markdown. XML & even JSON are not as human optimized, but still human usable.
- sedachv 7y ago
  > YAML and TOML were optimized for human reading and writing, like markdown. That was the rationalization, in reality I don't know what actual writing use case they were optimized for (Notepad?). XML in a syntax-aware editor with the help of automatic schema validation makes it far easier to write than YAML or TOML.
  - novok 7y ago
    I don't need a special editor to write out YAML (if it didn't have tab dependence) or TOML quickly. It's also a lot faster for a human to read vs XML. JSON is fairly readable, but a bit of a pain to write out compared to ini files, since you have to quote all strings. If your going into complicated things like schemas or other complicated structures, then you probably shouldn't be using YAML or TOML. I would mostly use it for config or other simple things. At this point if you are not interacting with 20 year old java software, that was created when JSON didn't exist and XML was king, you should be using TOML for simple config, JSON for most things and heavyweight XML, protobuf or csv for the specialized cases. And while we are at it, markdown for simple documentation. Even gradle decided to use groovy scripts as their config language because it's far more human readable and usable.
    - sedachv 7y ago
      > At this point if you are not interacting with 20 year old java software, that was created when JSON didn't exist and XML was king, you should be using TOML for simple config, JSON for most things and heavyweight XML, protobuf or csv for the specialized cases. You should be using S-expressions.
- gambler 7y ago

scott_s 7y ago

I agree. The author and other commenters here have not proposed an alternative which provides two features I consider critical to a generic data format: schema specification and validation; and easy parsing support in many ecosystems. JSON and Yaml don't seem to have mature, widely adopted schema specification and validation. And I'm not aware of anything outside of XML, JSON and Yaml which have such wide parsing support in so many different ecosystems.

theamk 7y ago
JsonSchema is pretty good -- it is not as widely used as XSD, but it has libraries for most languages. And of course JSON is the easiest thing to parse in scripting languages, like Python and Ruby -- the entire API is one line, and then you have a native structure you can work with.
- spiralx 7y ago
  > JsonSchema is pretty good -- it is not as widely used as XSD, but it has libraries for most languages. It's okay now that the newest revisions support more realistic use cases, but ironically I find it impossible to write as JSON... I write them as YAML which my validator supports natively :) It's still not as nice as RELAX-NG's compact schema format though IMO :) https://relaxng.org/compact-tutorial-20030326.html https://relaxng.org/compact-tutorial-20030326.html And the LXML library for Python was a pleasure to use compared to any other similar library I've used.

tannhaeuser 7y ago

> But for markup... we may be better off to just use markdown inside CDATA blocks No we arent't. markdown itself is literally specified as a shortform of HTML [1], and can be translated into canonical angle-bracket syntax using SGML short references (though not completely eg. markdown reference links require unlimited forward lookup). This gives a canonical representation of markdown in SGML/XML even if you don't use SGML. [1]: https://daringfireball.net/projects/markdown/ https://daringfireball.net/projects/markdown/