Why even are they URLs? The only reasonable suggestion I could find is that it was part of an abandoned or poorly adopted idea to also host the schema at that URL.
Probably the same sort of thought process that led to the convention of Java packages being named com.example.whatever. It identifies the creator and gives you some structure to create a unique identifier.
Lot of half-baked ideas floating around in the early years of the commercial internet, but the Java thing held up better.
Snarky answer: because they're the W3C and are high on their own supply ;-)
But it does allow more flexibility. If you don't want to be tied to a domain name, you can use a URN with a UUID like urn:uuid:4603d9d3-e895-4000-9077-0ab0f2776e1e
In addition to the uniqueness others have mentioned, where do you find the canonical definition of the schema if it doesn’t have a url? So they just cut out the mapping and made them one.
This is nonsensical. Where did you get the XSD from? You could get a proper spec from the same place. Contrast this with JSON, which makes zero attempt. People (generally) prefer that. If you were dead-set on embedding the documentation URL in the namespace, you could at least remove the tripping hazard and use new "protocol" like `xsd-spec://host/specs/foo/v1.2` or something.
I'm sure some braindead software out there attempts to retrieve namespace URIs, but it would surely be a drop in the bucket compared to traffic for schemas/DTDs (which are intended to be retrieved).
Comments
Escalating delays can help with this. Get it to be slow enough that people notice.
XML schemas have had a similar history, tanking w3c.org servers.
They totally deserved it for making namespaces that "just happen to be" URLs. XML is insane.
Ah I remember the good old days of strict XML parsers that would fail if they didn't have Internet access to pull the schema in.
Which you didn’t figure out for a while and so your CI/CD pipeline and dev code/build/test cycles hammer their servers for months.
Then you prefetch to fix that problem, and now some slow calls you hadn’t gotten to the bottom of suddenly aren’t.
well, but they're URIs. See, the difference is right there. An identifier not a location. Nobody should ever confuse the two!
/s of course
Why even are they URLs? The only reasonable suggestion I could find is that it was part of an abandoned or poorly adopted idea to also host the schema at that URL.
Probably the same sort of thought process that led to the convention of Java packages being named com.example.whatever. It identifies the creator and gives you some structure to create a unique identifier.
Lot of half-baked ideas floating around in the early years of the commercial internet, but the Java thing held up better.
It's a way to ensure global uniqueness. In the end they're just compared byte-for-byte as strings.
Precisely, so why are they URLs and not something like Java's packages? Or just a URL without the `http://`?
Snarky answer: because they're the W3C and are high on their own supply ;-)
But it does allow more flexibility. If you don't want to be tied to a domain name, you can use a URN with a UUID like urn:uuid:4603d9d3-e895-4000-9077-0ab0f2776e1e
You could also just do `com.mydomain.uid.4603d....` if you wanted. But yeah I think your snarky answer is probably more than a little true!
In addition to the uniqueness others have mentioned, where do you find the canonical definition of the schema if it doesn’t have a url? So they just cut out the mapping and made them one.
This is nonsensical. Where did you get the XSD from? You could get a proper spec from the same place. Contrast this with JSON, which makes zero attempt. People (generally) prefer that. If you were dead-set on embedding the documentation URL in the namespace, you could at least remove the tripping hazard and use new "protocol" like `xsd-spec://host/specs/foo/v1.2` or something.
Schemas != namespaces.
I'm sure some braindead software out there attempts to retrieve namespace URIs, but it would surely be a drop in the bucket compared to traffic for schemas/DTDs (which are intended to be retrieved).