4 ms·

If you're using Schemas for your XML then you need namespaces in case you've got two different elements from different schemas that have the same name. (We use

If you're using Schemas for your XML then you need namespaces in case you've got two different elements from different schemas that have the same name. (We use schemas for all of our XML, because that way we can generate strongly-typed objects from them.)

tonyedgecombe 5y ago
>If you're using Schemas for your XML then you need namespaces in case you've got two different elements from different schemas that have the same name. Isn't that where the problems start, I'm willing to bet 99% of XML documents don't have more than one schema. We have ended up with a ton of complexity to support a minority of use cases. It's no wonder people embraced JSON.
- buzer 5y ago
  These days I wouldn't be surprised if fairly large portion of XML documents that are still in use/produced did have multiple schemas. Most of the simple use cases have already moved to JSON or similar formats. One very common case where there are multiple schemas is SAML. SAML protocol responses have their own schema, SAML assertions have their own schema, assertions usually define their type with different schema (XML schema instance) & XML signatures have their own schema. https://www.samltool.com/generic_sso_res.php https://www.samltool.com/generic_sso_res.php for example
- codeulike 5y ago
  yes exactly, they tried to make xml V1 cover every eventuality for all time and created a fussy mess
- le-mark 5y ago
  So many schemas are all or nearly all optional elements, so the point about typing rarely works oh in practice.
- usrusr 5y ago
  Even worse than that: 99% of all schemas mandate exclusivity (or at least exclusive subtrees, it's been a while). The dominant schema techniques rule out markup unless you explicitly bends over for it while jumping through hoops.
codeulike 5y ago
Yes I know its got a use and it makes sense when stated simply but when you get into the details everything about XML is so excessive because they tried to cover everything, so then you have namespaces and default namespaces and target namespaces and because the schemas are also defined in XML you get DTDs and XSDs and you end up trying to describe arbitrary contraints using really fiddly tags. The way JSON just kindof waltzed along and took over, despite the obvious drawbacks of it being schema-less, is really interesting.
- saurik 5y ago
  I would argue the file format had nothing to do with JSON being popular: it is much much easier to generate and access an object that is essentially a native serialization format, so even if you never ever see the XML (and thereby never have to deal with the namespace rules) JSON was going to win over XML for a developer in JavaScript, certainly.. and then the format is also trivially mappable to almost any other language as JavaScript is so devoid of types.
  - ludamad 5y ago
    At this point, if I don't need efficiency I just use JSON as my wire format. Need to integrate a C++ card game engine with emscripten? I expose 2 functions, one that dumps all as JSON and one that accepts legal moves. The JSON syntax is pretty irrelevant except for light debugging - however, the easy mapping without fussing over many alternate representations is quite relevant

tonyedgecombe 5y ago

>If you're using Schemas for your XML then you need namespaces in case you've got two different elements from different schemas that have the same name. Isn't that where the problems start, I'm willing to bet 99% of XML documents don't have more than one schema. We have ended up with a ton of complexity to support a minority of use cases. It's no wonder people embraced JSON.

buzer 5y ago
These days I wouldn't be surprised if fairly large portion of XML documents that are still in use/produced did have multiple schemas. Most of the simple use cases have already moved to JSON or similar formats. One very common case where there are multiple schemas is SAML. SAML protocol responses have their own schema, SAML assertions have their own schema, assertions usually define their type with different schema (XML schema instance) & XML signatures have their own schema. https://www.samltool.com/generic_sso_res.php https://www.samltool.com/generic_sso_res.php for example
codeulike 5y ago
yes exactly, they tried to make xml V1 cover every eventuality for all time and created a fussy mess
le-mark 5y ago
So many schemas are all or nearly all optional elements, so the point about typing rarely works oh in practice.
usrusr 5y ago
Even worse than that: 99% of all schemas mandate exclusivity (or at least exclusive subtrees, it's been a while). The dominant schema techniques rule out markup unless you explicitly bends over for it while jumping through hoops.

codeulike 5y ago

Yes I know its got a use and it makes sense when stated simply but when you get into the details everything about XML is so excessive because they tried to cover everything, so then you have namespaces and default namespaces and target namespaces and because the schemas are also defined in XML you get DTDs and XSDs and you end up trying to describe arbitrary contraints using really fiddly tags. The way JSON just kindof waltzed along and took over, despite the obvious drawbacks of it being schema-less, is really interesting.

saurik 5y ago
I would argue the file format had nothing to do with JSON being popular: it is much much easier to generate and access an object that is essentially a native serialization format, so even if you never ever see the XML (and thereby never have to deal with the namespace rules) JSON was going to win over XML for a developer in JavaScript, certainly.. and then the format is also trivially mappable to almost any other language as JavaScript is so devoid of types.
- ludamad 5y ago
  At this point, if I don't need efficiency I just use JSON as my wire format. Need to integrate a C++ card game engine with emscripten? I expose 2 functions, one that dumps all as JSON and one that accepts legal moves. The JSON syntax is pretty irrelevant except for light debugging - however, the easy mapping without fussing over many alternate representations is quite relevant