This would've been useful if you knew what kind of number it was...

As for what goes into separate elements and what goes into attributes: a typical answer to this is that simple types (as per XSL) go into attributes, complex types go into elements.

Compare this to JSON's screwed-up definition of "hash-tables" (the things in curly braces) which doesn't require that "keys" be unique.

XML wasn't perfect. But JSON isn't really better. It sucks in a slightly different way because people keep inventing these formats w/o much thinking, and once discover problems, don't fix them.

JSON isn’t ambiguous when it comes to this. Numbers are arbitrary precision decimal numbers[1].

I’m guessing your issue is with how Javascript interprets JSON numbers as 32 bit floats. But that is a (mis-)feature of JavaScript and switching your serialization format to XML would not help, because JavaScript represents all numbers as 32-bit floats.

[1] https://www.json.org/json-en.html

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, at least up to the point where JSON's simple type system is no longer expressive enough, then you need - just as with XML - a schema to get the correct type information, for example to distinguish actual strings and dates.

If you really need this, nobody stops you from including type information in XMLs, have a type attribute on elements or <quote>"strings"</quote> as compared to <numbers>123</numbers> and use that. You will of course have to do this on your own, that is just not the way XML is supposed to be used.

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.

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.

No. I'm complaining that JSON is too limited. And that it's "type system" is lacking so much that I have to resort to hacks like encoding numbers in strings. Which I think is embarrassing for an industry.

> There's standard to encode dates to string. It's called ISO-8601 and it's supported everywhere.

It's not. Too many servers and services use formats other than ISO-8601. Should I call Visa that their export formats suck? Or that Random API that their JSON datefields should be changed to ISO-8601. It's supported in most languages. But e.g. something widely used as Google Sheets doesn't support this: If you get a JSON or CSV with ISO-8601 into Google sheets, a lot of string parsing and even regexes are needed to turn it into a proper date.

Saying "we use ISO-8601 and that solved everything" only works if you never need any service outside of yours and never interop or exchange data with other services. Which in practice is never for anything remotely successful.

I have yet to see Time be easy. Anywhere. At all. From daylight savings being state-dependent, system times resetting to rand, right down to CPU monotonic timing.

Using Time handling as a criticism to JSON's architecture doesn't hold water.

You mean a float, right?

But JSON doesn't disallow arbitrary precision numbers, that's up to the parser implementation.

   number
    integer fraction exponent

That's exactly what I'm doing. And indeed another reason why I feel embarrassed by JSON. I mean, we -the industry- have been doing financial data transport over computer networks, for how long now? fifty years? And we keep "inventing" transport formats that unsolve issues that have long been solved and done. XML had this solved[1]. Hell, even the ancient MT940[2] had this solved.

[1] https://web.archive.org/web/20200618100100/https://deutscheb... (pdf warning) [2] e.g. https://financialdataexchange.org/FDX/About/OFX-Work-Group.a...

> At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types.

Unless I’m missing your meaning, this seems like an apples-to-oranges comparison. HTML is not a general-purpose format like JSON. It’s a very complicated document format that is validated with reference to an external spec.

I think XML is a great fit for a document format that can become arbitrarily complex yet still easy to author and validate. It’s obviously a really poor fit for a wire transport protocol.

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]'

   jq "." <<< "[null]"     
   [
     null
   ]
   
   jq "." <<< "undefined"
   parse error: Invalid numeric literal at line 2, column 0

`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.

that's the point.

The official JSON serializer from every broswer vendor and every Node installation produce invalid JSON.

Which for the JavaScriptObjectNotation is kinda hilarious.

> Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()`

I would expect `JSON.stringify` to give an error if trying to serialize something that naturally does not map to JSON, like many other libraries do.

You have to provide a manual override for those situations.

But JavaScript and ECMA (`JSON.stringify` is defined in the standard) decided that no, they can ignore the specs for some reason.

Problem is they can't fix it now, because too many applications rely on those wrong assumptions.

Here it is the reason why you can find <flag>true</flag> and <flag>1</flag>

Difference being XML was born to standardize the document format, JSON aspired to be a data format but failed miserably at it, even at the most basic level, like saying an int from a float. The spec is simply too vague and ambiguous to give some guarantee of interoperability, beyond numbers and strings.

Maybe we should all switch to MessagePack

    > JSON.stringify(42)
    '42'
    > JSON.stringify(undefined)
    undefined
    > typeof JSON.stringify(42)
    'string'
    > typeof JSON.stringify(undefined)
    'undefined'

I don't think I agree with this. `JSON.stringify` isn't producing JSON when it returns `undefined`. Instead...

> I would expect `JSON.stringify` to give an error if trying to serialize something that naturally does not map to JSON, like many other libraries do.

> You have to provide a manual override for those situations.

... `undefined` is an error. As in, there's no meaningful difference between catching an exception and providing "a manual override" for `undefined`, is there?

> But JavaScript and ECMA (`JSON.stringify` is defined in the standard) decided that no, they can ignore the specs for some reason.

What part of what spec is being ignored? `JSON.stringify` conforms to its own spec, as you say; and when it returns JSON, the JSON is valid. Meanwhile the JSON spec itself is very explicit about not declaring rules for serialisation/deserialisation:

The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax. It also intentionally does not define how a valid JSON text might be internalized into the data structures of a programming language. There are many possible semantics that could be applied to the JSON syntax and many ways that a JSON text can be processed or mapped by a programming language. Meaningful interchange of information using JSON requires agreement among the involved parties on the specific semantics to be applied. Defining specific semantic interpretations of JSON is potentially a topic for other specifications.

XML is a language for marking up text. SVG uses attributes for all vector data, because the vector points are not meant to be presented to a user as raw data.

If I embed a SVG into a XHTML document and the browser does not understand SVG, the text within the graphic is still presented to the user.

> Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently:

This is not a responsibility of XML, which deals in a common well-formed markup format for various document format.

It sounds like you are dealing with a tool that has defined an XML-based data interchange format, and that they may have inconsistent tooling for their format.

I think a good rule of thumb is that attributes are for key/value pairs that are probably not user-visible and definitely not directly user-editable.

Carried to a logical conclusion, this would simplify the auto-creation of form GUIs.

Are you ok with <a href="..">link</a>?

That was kind of my original point, people are fine with html but don't like XML. I think the real reason people don't like XML is it reminds them of Steve Ballmer.