81–90 of 150 posts
IS there an on-premise alternative? Not necessarily speaking of schemastore.org on prem but a service comparable in spirit.
It's a pity the catalog format doesn't support an 'import' or relative URLs for schemas - would have made local extensions a bit easier.
Earlier quoted context omitted.
JSON is a much better serialization format since XML was designed as a document format. For example, there is no standardized way to serialize a string with a null character even if you escape it (this is allowed in many programming languages). JSON just says do “\0” and calls it a day. I’m not sure if it’s better for users, but it’s certainly easier to work with as a dev. HTML isn’t trying to serialize abstract data…
Try using UTF-8 encoding for XML, and your problems with zero byte encoding will go away. Your understanding of "easier" is oversimplified to the point that it's wrong. It's easier to do the wrong thing in JSON, it's harder to do the right thing in JSON (compared to XML). JSON is a poorly thought-out format. It's problems become progressively more difficult to deal with the more you expect of your program.
Earlier quoted context omitted.
Only the first one will be treated as a boolean in JSON. The second one is a number, and the third is a string.
Well, it's the same in XML, more or less. [1] The difference is that XML cleanly separates types and data, all the type information is in the schema and there is no type information in the data, so without a schema you can not properly type the data. JSON on the other hand does not separate types and data, the types are implicitly contained in the data. So you can get type information from the data without a schema,…
Which, in practice, is a terrible oversight. I've honestly never seen a JSON store/transport/serde in practice without dates and/or times in them. There's always some updated_at or captured_on somewhere in the API or dataset.
Of all the data-types needed, I'd say dates are amongst the most important. At least more important in practice than floats; which JSON does support for odd reasons. Especially with dates being ambigous at best and inconsistent at worst.
Pubquiz: when was/or will be, how much paid? { currency: "THB", paid_at: "04-03-2566", amount: 13.37 }¹ - JSON is neat for simple use-cases, but utterly impractical for when precision and correctness is required. Yet here we are, building around and on top of it, to get that correctness and precision.
¹I'm messing a bit, 'cause this calendar isn't used in practice for such use-cases anymore. Hardly. But I've seen this with Hijri calendars. And those silly US date-formats. I've seen it "solved" with complex structs like { created_at: { year: 2022, day: ... , timezone:xxx}". I've myself "fixed" floating-point precision issues in financial applications that used JSON by using all-strings: "{ currency: "USD", amount_in_cents: "1337" } and such.
JSON Resume uses a defined schema. (listed on schemastore.org) It has made writing resumes with co pilot super powerful.
Earlier quoted context omitted.
JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grows around a particular technology.
There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far f…
It's not about the time it takes to learn about namespaces. I'm talking about the complexity that namespaces and entities add to the data model and the requirement to actually handle them throughout the entire stack.
You can normalise and compare arbitrary pieces of JSON using only information available locally in that same sequence of UTF-8 bytes. You cannot do that with XML. You have to consider the whole document context and resolve all namespaces and entities before actually comparing anything.
The JSON specification is ~5 pages and most of that is diagrams. The XML specification is ~40 pages long and it imports ~60 pages of URI specification.
I'm not saying that it's impossible to use only the simple parts of XML unless and until you actually need what namespaces have to offer. But that's culture, and you have no control over other people's culture.
Earlier quoted context omitted.
Well, it's the same in XML, more or less. [1] The difference is that XML cleanly separates types and data, all the type information is in the schema and there is no type information in the data, so without a schema you can not properly type the data. JSON on the other hand does not separate types and data, the types are implicitly contained in the data. So you can get type information from the data without a schema,…
> a schema to get the correct type information, for example to distinguish actual strings from dates. Which, in practice, is a terrible oversight. I've honestly never seen a JSON store/transport/serde in practice without dates and/or times in them. There's always some updated_at or captured_on somewhere in the API or dataset. Of all the data-types needed, I'd say dates are amongst the most important. At least more im…
There's standard to encode dates to string. It's called ISO-8601 and it's supported everywhere.
Also JSON poses no particular limits which would force anyone to encode string as number.
Earlier quoted context omitted.
Well, it's the same in XML, more or less. [1] The difference is that XML cleanly separates types and data, all the type information is in the schema and there is no type information in the data, so without a schema you can not properly type the data. JSON on the other hand does not separate types and data, the types are implicitly contained in the data. So you can get type information from the data without a schema,…
> a schema to get the correct type information, for example to distinguish actual strings from dates. Which, in practice, is a terrible oversight. I've honestly never seen a JSON store/transport/serde in practice without dates and/or times in them. There's always some updated_at or captured_on somewhere in the API or dataset. Of all the data-types needed, I'd say dates are amongst the most important. At least more im…
Lots of comments here about XML vs. JSON... but there are areas where these two don't collide. I'm thinking about text/document encoding (real annotated text, things like books, etc). Even though XML is still king here (see TEI and other norms), some of its limitations are a problem. Consider the following text: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dol…
You are absolutely right that XML is better for document structures. My current theory is that Yjs [0] is the new JSON+XML. It gives you both JSON and XML types in one nested structure, all with conflict free merging via incremental updates. Also, you note the issue with XML and overlapping inline markup. Yjs has an answer for that with its text type, you can apply attributes (for styling or anything else) via arbata…
Earlier quoted context omitted.
The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags? Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently: true versus 1 Some systems require the token "true", others will only treat 1 as the boolean true. For example, MS claims that for exchange ASD boolean values must be integer 1 o…
> you don't need a separate definition file for basic, primitive data types. unless you need something different from JavaScript primitive data types. For example integers . Or null means nothing to you. Or you want a faithful representation of input Welcome to Node.js v20.5.1. Type ".help" for more information. > JSON.stringify(undefined) undefined > JSON.stringify([undefined]) '[null]' but then jq "."
`JSON.stringify()` is documented to behave exactly as you demonstrate, so there's no surprises:
undefined, Function, and Symbol values are not valid JSON values. If any such values are encountered during conversion, they are either omitted (when found in an object) or changed to null (when found in an array). JSON.stringify() can return undefined when passing in "pure" values like JSON.stringify(() => {}) or JSON.stringify(undefined).
Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()` and so should be parsed on that basis seems ... odd? I don't see any problem with what `jq` is doing there, but anyway I don't see a problem with JSON itself in these examples.
There are some YAML based schemas there too. How does this work, is there a canonical YAML->JSON transformation, or does JSON schema spec have explicit YAML support? edit: skipping the theoretical foundations, there seems to be at least this tool that claims to validate yaml against json schema: https://github.com/json-schema-everywhere/pajv