3 ms·

I've been using XML here and there for about 20 years now. It does have its uses. But I still don't have any idea what all that xmlns stuff is about, especially

I've been using XML here and there for about 20 years now. It does have its uses. But I still don't have any idea what all that xmlns stuff is about, especially all the variations of it that involve colons. Like I know its something to do with namespaces or whatever. But to this day I open an XML file and in the first few lines there's a few xmlns pointing to some random complicated old urls and it just has this air of 'ignorable old overspecified thing because someone got too excited twenty years ago' (except sometimes its not ignorable and then things get messy) edit: yes I know what namespaces are for, and some of the simple uses are simple, but to try and understand xml namespaces and schemas in full is really complicated. 95% of the time this stuff just seems like fussy cruft.

AndrewDucker 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. (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
oreille 5y ago
Well it might look old, but it actually solved the whole JSON schema declaration and validation problem before JSON even existed - and it's embed into the standard.
saurik 5y ago
Namespaces allow you to mix and match document markup formats without conflicts, and without just praying that no one else happened to use the same prefix as you did.
dwaite 5y ago
> But I still don't have any idea what all that xmlns stuff is about Basically, they that by "extensible" they both wanted to support custom document markup languages/structures, but also the ability to extend those documents without needing to coordinate naming, etc. But they messed it up by defining namespaces as an add-on to the core XML spec, rather than part of the spec itself. They also made 1-2 important errors in the definition of that add-on. This led to XML tools being modal, having to support an interpretation of a document treating "xmlns" as a regular attribute and one where it was a namespace that influenced the interpretation of all the attributes/elements. This push of complexity onto the people building schemas and using tools grew as there were two camps - one which wanted XML to be about generic tools that work on all XML data (similar to JSON today) and one where you used XML to define a specific document format for consumption by format-specific tools. Various specifications were led by the generic tooling camp or document centric camp. As a result, XML eventually wound up being a poor fit for both.
- codeulike 5y ago
  Interesting, thanks
- deleted 5y ago
  [deleted]
- le-mark 5y ago
  > But they messed it up by defining namespaces as an add-on to the core XML spec, rather than part of the spec itself. An example of where this is an issue is using version as a name space ie tags with the form “<v2:customer>” and apply xslt on “<customer>”. Since they’re strings, they don’t match. The standard xslt solution is to strip the namespace from offending elements. Or change all your xslt. I learned this in an app with a few 100k lines of xslt.
AlbertoGP 5y ago
The mistake with the namespace syntax is that they wanted to allow plain textual copy-and-paste to work, thus the different ways and places in the document where namespaces can be declared. The big thing we missed was better tools from the get-go, specially xml-aware text editors. That’s why the editors of the XML specification wanted to make things a bit easier for people doing things like writing XML with a plain text editor, or line-oriented processing using Perl. I think the amount of grief we are stuck with because of those time-limited needs is not worth it, thus the word “mistake” in the beginning of this post. In hindsight, if anyone asked me how to add namespace support for XML, I would have required them all to be declared at the root of the document, in the XML declaration: <?xml version="1.0" standalone="yes" xmlns="https://docbook.org/ns/docbook" xmlns:m="http://fake-w3.org/2001/Math/not-the-real-MathML"?> <book> ... <equation> <title>MathML example</title> <m:math mode="display"> <m:row> <m:underover> <m:o>∑</m:o> <m:row> <m:i>x</m:i> <m:o>=</m:o> <m:i>a</m:i> </m:row> <m:row> <m:i>b</m:i> </m:row> </m:underover> <m:sqrt> <m:i>x</m:i> </m:sqrt> </m:row> </m:math> </equation> </book> Additionally, I would require them to be unique: only one prefix per namespace. That would eliminate a lot of issues when writing XML processors, including editors. I guess someone else mentioned this or a very similar idea at the time, and it was discarded to support plain text copy-and-paste by having the xmlns attribute in the element being copy-and-pasted. I don’t claim I would have done a better job, but I wish for a new version of XML that learns from these two and a half decades of use.

AndrewDucker 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. (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

oreille 5y ago

Well it might look old, but it actually solved the whole JSON schema declaration and validation problem before JSON even existed - and it's embed into the standard.

saurik 5y ago

Namespaces allow you to mix and match document markup formats without conflicts, and without just praying that no one else happened to use the same prefix as you did.

dwaite 5y ago

> But I still don't have any idea what all that xmlns stuff is about Basically, they that by "extensible" they both wanted to support custom document markup languages/structures, but also the ability to extend those documents without needing to coordinate naming, etc. But they messed it up by defining namespaces as an add-on to the core XML spec, rather than part of the spec itself. They also made 1-2 important errors in the definition of that add-on. This led to XML tools being modal, having to support an interpretation of a document treating "xmlns" as a regular attribute and one where it was a namespace that influenced the interpretation of all the attributes/elements. This push of complexity onto the people building schemas and using tools grew as there were two camps - one which wanted XML to be about generic tools that work on all XML data (similar to JSON today) and one where you used XML to define a specific document format for consumption by format-specific tools. Various specifications were led by the generic tooling camp or document centric camp. As a result, XML eventually wound up being a poor fit for both.

codeulike 5y ago
Interesting, thanks
deleted 5y ago
[deleted]
le-mark 5y ago
> But they messed it up by defining namespaces as an add-on to the core XML spec, rather than part of the spec itself. An example of where this is an issue is using version as a name space ie tags with the form “<v2:customer>” and apply xslt on “<customer>”. Since they’re strings, they don’t match. The standard xslt solution is to strip the namespace from offending elements. Or change all your xslt. I learned this in an app with a few 100k lines of xslt.

AlbertoGP 5y ago

The mistake with the namespace syntax is that they wanted to allow plain textual copy-and-paste to work, thus the different ways and places in the document where namespaces can be declared. The big thing we missed was better tools from the get-go, specially xml-aware text editors. That’s why the editors of the XML specification wanted to make things a bit easier for people doing things like writing XML with a plain text editor, or line-oriented processing using Perl. I think the amount of grief we are stuck with because of those time-limited needs is not worth it, thus the word “mistake” in the beginning of this post. In hindsight, if anyone asked me how to add namespace support for XML, I would have required them all to be declared at the root of the document, in the XML declaration: <?xml version="1.0" standalone="yes" xmlns="https://docbook.org/ns/docbook" xmlns:m="http://fake-w3.org/2001/Math/not-the-real-MathML"?> <book> ... <equation> <title>MathML example</title> <m:math mode="display"> <m:row> <m:underover> <m:o>∑</m:o> <m:row> <m:i>x</m:i> <m:o>=</m:o> <m:i>a</m:i> </m:row> <m:row> <m:i>b</m:i> </m:row> </m:underover> <m:sqrt> <m:i>x</m:i> </m:sqrt> </m:row> </m:math> </equation> </book> Additionally, I would require them to be unique: only one prefix per namespace. That would eliminate a lot of issues when writing XML processors, including editors. I guess someone else mentioned this or a very similar idea at the time, and it was discarded to support plain text copy-and-paste by having the xmlns attribute in the element being copy-and-pasted. I don’t claim I would have done a better job, but I wish for a new version of XML that learns from these two and a half decades of use.