5 ms·

I like XML. It works well, typed and reliable, supported everywhere, great IDE support. I don't have much experience with JSON schemas, but what they failed to

I like XML. It works well, typed and reliable, supported everywhere, great IDE support. I don't have much experience with JSON schemas, but what they failed to work when I tried one time.

nine_k 4y ago
JSON schemas are modeled closely after XML schemas. (I wrote a fair amount of both.) I wonder when XSLT will be re-invented and applied to JSON and YAML. (XSLT was a bit of a miracle: a pure functional language adopted by a significant chunk of non-CS community in early 2000s. The syntax forced by XML sucked though. YAML can do better!)
- zvr 4y ago
  Take a look at "invisible" XML, https://invisiblexml.org/ https://invisiblexml.org/, where they try to omit tags that can be inferred by a grammar.
  - nine_k 4y ago
    XML as a unified format for parse trees? Fine. (Could use S-expressions as well. The approach is 60+ years old now...)
- int_19h 4y ago
  XQuery was, in many ways, XSLT with sane syntax.
- theteapot 4y ago
  > JSON schemas are modeled closely after XML schemas. Are you talking specifically about XSD and JSONSchema? If so I don't think this is really true. Pretty sure the original authors of JSONSchema didn't pay much attention to XSD.
  - magicalhippo 4y ago
    I don't know if they were looking at XSD, but I did write an XSD to JSON Schema[1] converter in an afternoon which does an almost perfect 1:1 mapping of a non-trivial XSD, including choice elements, basic restrictions etc. So for a lot of XSD's I'd say JSON Schema is effectively very close. Sadly, tooling for the latest JSON Schema (which is required for choice elements IIRC) is lacking, Swagger UI for example does not work well with it for example. [1]: https://json-schema.org/draft/2020-12/json-schema-core.html https://json-schema.org/draft/2020-12/json-schema-core.html
    - theteapot 4y ago
      > I did write an XSD to JSON Schema[1] converter in an afternoon which does an almost perfect 1:1 mapping of a non-trivial XSD ... Can it do the reverse?
      - magicalhippo 4y ago
        That I haven't considered, given that at our work we had a bunch of XSD's and wanted to expand our integration point to accept JSON. I don't see any big issues with doing it in reverse for a subset of JSON Schema. What I haven't looked at is how large that subset would be. That is, if JSON Schema contains things that aren't possible to represent in XSD. For example, JSON Schema allows for some extensive conditional sub-schema logic. I used the "oneOf" to represent a XSD choice element, however JSON Schema also allows for such things as "if..then..else", which as a self-taught non-expert on XSD's I'm not sure how would map to XSD on a Saturday morning. Of course, there are things in XSD which can't be represented in JSON Schema either, I'm sure it's easy to come up with something that doesn't map. But from the typical XSD's I've seen and the ones we had in our company, the mapping could be done with just a single special-case. Given the lack of tooling around JSON Schema, my workflow now is to create/update the XSD and regenerate the JSON Schema.
- manbart 4y ago
  Current versions of XSLT, XQuery and XPath support JSON natively now.
- eyelidlessness 4y ago
  I‘m currently working on yanking a bit of XSLT out and reimplementing it in procedural DOM code—currently as in I have spent the last month on this, and hope to have it in a PR tomorrow. I share your stated preference for pure functions, and their accessibility to people who aren’t explicitly programmers, and I share your implied preference for declarative programming to achieve that. Unfortunately my specific use case needs at least to become more procedural before I can take it further, but I’ve at least structured the code so it’s adaptable to pure functions in the future. I really don’t think YAML and its own terse but ambiguous rules are better suited. The problem I’ve found in XSLT during this effort, and in YAML in the past, is there’s no debugging story that isn’t full of pain and mysterious grasping in the dark. I know actually functional languages like lisps do this better. I strongly suspect more declarative logic languages do better still. I also know from experience that the Excel interfaces most of our users interface are better than the XML experience, and I strongly suspect that’s closer to the pure/declarative + non-programming-accessible ideal than a markup language suited to other purposes.
- mdaniel 4y ago
  > I wonder when XSLT will be re-invented and applied to JSON and YAML. That's jq and its gojq friend (for its `--yaml-input`), right? If not a standard, damn near one as best I can tell. JMESPath (used by awscli and ansible) is a joke compared to the expressiveness of jq. There's also JSONPath in kubectl but it is similarly nowhere near as awesome as jq and not even complete in its attempt to be "XPath for JSON"
eddsh1994 4y ago
You can add types to JSON but it gets pretty funky, essentially sibling values. Pretty sure Google has some online details on how they try to keep JSON manageable internally.

I like XML. It works well, typed and reliable, supported everywhere, great IDE support. I don't have much experience with JSON schemas, but what they failed to work when I tried one time.

nine_k 4y ago

JSON schemas are modeled closely after XML schemas. (I wrote a fair amount of both.) I wonder when XSLT will be re-invented and applied to JSON and YAML. (XSLT was a bit of a miracle: a pure functional language adopted by a significant chunk of non-CS community in early 2000s. The syntax forced by XML sucked though. YAML can do better!)

zvr 4y ago
Take a look at "invisible" XML, https://invisiblexml.org/ https://invisiblexml.org/, where they try to omit tags that can be inferred by a grammar.
- nine_k 4y ago
  XML as a unified format for parse trees? Fine. (Could use S-expressions as well. The approach is 60+ years old now...)
int_19h 4y ago
XQuery was, in many ways, XSLT with sane syntax.
theteapot 4y ago
> JSON schemas are modeled closely after XML schemas. Are you talking specifically about XSD and JSONSchema? If so I don't think this is really true. Pretty sure the original authors of JSONSchema didn't pay much attention to XSD.
- magicalhippo 4y ago
  I don't know if they were looking at XSD, but I did write an XSD to JSON Schema[1] converter in an afternoon which does an almost perfect 1:1 mapping of a non-trivial XSD, including choice elements, basic restrictions etc. So for a lot of XSD's I'd say JSON Schema is effectively very close. Sadly, tooling for the latest JSON Schema (which is required for choice elements IIRC) is lacking, Swagger UI for example does not work well with it for example. [1]: https://json-schema.org/draft/2020-12/json-schema-core.html https://json-schema.org/draft/2020-12/json-schema-core.html
  - theteapot 4y ago
    > I did write an XSD to JSON Schema[1] converter in an afternoon which does an almost perfect 1:1 mapping of a non-trivial XSD ... Can it do the reverse?
    - magicalhippo 4y ago
      That I haven't considered, given that at our work we had a bunch of XSD's and wanted to expand our integration point to accept JSON. I don't see any big issues with doing it in reverse for a subset of JSON Schema. What I haven't looked at is how large that subset would be. That is, if JSON Schema contains things that aren't possible to represent in XSD. For example, JSON Schema allows for some extensive conditional sub-schema logic. I used the "oneOf" to represent a XSD choice element, however JSON Schema also allows for such things as "if..then..else", which as a self-taught non-expert on XSD's I'm not sure how would map to XSD on a Saturday morning. Of course, there are things in XSD which can't be represented in JSON Schema either, I'm sure it's easy to come up with something that doesn't map. But from the typical XSD's I've seen and the ones we had in our company, the mapping could be done with just a single special-case. Given the lack of tooling around JSON Schema, my workflow now is to create/update the XSD and regenerate the JSON Schema.
manbart 4y ago
Current versions of XSLT, XQuery and XPath support JSON natively now.
eyelidlessness 4y ago
I‘m currently working on yanking a bit of XSLT out and reimplementing it in procedural DOM code—currently as in I have spent the last month on this, and hope to have it in a PR tomorrow. I share your stated preference for pure functions, and their accessibility to people who aren’t explicitly programmers, and I share your implied preference for declarative programming to achieve that. Unfortunately my specific use case needs at least to become more procedural before I can take it further, but I’ve at least structured the code so it’s adaptable to pure functions in the future. I really don’t think YAML and its own terse but ambiguous rules are better suited. The problem I’ve found in XSLT during this effort, and in YAML in the past, is there’s no debugging story that isn’t full of pain and mysterious grasping in the dark. I know actually functional languages like lisps do this better. I strongly suspect more declarative logic languages do better still. I also know from experience that the Excel interfaces most of our users interface are better than the XML experience, and I strongly suspect that’s closer to the pure/declarative + non-programming-accessible ideal than a markup language suited to other purposes.
mdaniel 4y ago
> I wonder when XSLT will be re-invented and applied to JSON and YAML. That's jq and its gojq friend (for its `--yaml-input`), right? If not a standard, damn near one as best I can tell. JMESPath (used by awscli and ansible) is a joke compared to the expressiveness of jq. There's also JSONPath in kubectl but it is similarly nowhere near as awesome as jq and not even complete in its attempt to be "XPath for JSON"

eddsh1994 4y ago

You can add types to JSON but it gets pretty funky, essentially sibling values. Pretty sure Google has some online details on how they try to keep JSON manageable internally.