3 ms·

I just can't fathom why they chose to use URLs--with a protocol--to define namespaces? By all means use the DNS, but bar.foo.example.com would have been such a

by yrro 3y ago

I just can't fathom why they chose to use URLs--with a protocol--to define namespaces? By all means use the DNS, but bar.foo.example.com would have been such a better choice than http://example.com/foo/bar http://example.com/foo/bar!

tannhaeuser 3y ago
Even the original designers of XML (those responsible for subsetting XML from SGML, and those responsible for dropping the ball by adding XML namespaces on top ;) aren't happy with it [1]. As to why URIs, I completely agree. I think URIs/URLs were introduced by TBL as arguably the major feat of HTML over generic SGML along with <a> and so phenomenally successful every W3C mechanism of name resolution and namespacing had to make use if it; RDF is littered with namespaces as well. [1]: https://blog.jclark.com/2010/01/xml-namespaces.html https://blog.jclark.com/2010/01/xml-namespaces.html
- arethuza 3y ago
  That's quite fascinating - shows how you can have a design process where every step is completely reasonable but the end-result can still be horrible!
andyjohnson0 3y ago
As you say, its piggybacking on the dns's uniqueness guarantee. Urls do at least provide and obvious way to have multiple namespaces per domain. But I agree that it's confusing. I once had the misfortune to have to use a third-party xml-based webservice whos developers thought that the xml namespace had to match the url used to access it. So their production and test systems had completely different namespaces. They maintained multiple xsd schemas for each system that only differed by namespace. When I finally managed to explain namespaces to their "chief web architect" he got all embarrassed. This was back in .net 4.x days, and I was generating serialisation classes from their schemas - so I had to create two different dlls and load the appropriate one at runtime. Very aggravating.
- yrro 3y ago
  good grief
Communitivity 3y ago
The W3C has all their specs, as far as I know, use Uniform Resource Identifiers (URIs), and most use the subset of Uniform Resource Locators (URLs). There seems to be a strong sentiment against using other types of identifiers, based on my experience on the Extensible Resource Identifier (XRI) technical committee in OASIS. So the chance that they'd create a new one for XPath was probably very unlikely, in my opinion. Even non-URL URIs might have been better for XPATH namespaces. As an aside, I haven't used XPath in a few years, but use JSONPath / JSONPointer on multiple days each week, and highly recommend them. I find XML to be great for many things, but I find JSON much easier to work with.
jerf 3y ago
The idea is that the URL can do something, like link to specification or something. However, there is nothing mandatory the URL has to do whatsoever. I think in practice you can treat it as an opaque blob and if you want to just declare a namespace as "bar.foo.example.com" I think it would work just about everywhere. There's enough legacy, but still in use, namespaces that aren't full legal URIs that libraries will never be able to start enforcing it, and since there's effectively no utility in forcing them to be URIs anyhow I doubt it'll suddenly become an issue when all the libraries decide to become compliant. Given that it's a bit bizarre to have a URI to something that doesn't have to even so much as exist, I can't see the standards bodies every getting very fussy about this either. Backing it down to just being "some agreed-upon blob value" would be backwards compatible anyhow.
- arethuza 3y ago
  "However, there is nothing mandatory the URL has to do whatsoever" To be honest I think that just added to the confusion - the idea of using a URI that was just a unique name and not something that actually referred to anything wasn't the easiest thing to appreciate.

by yrro 3y ago

tannhaeuser 3y ago

Even the original designers of XML (those responsible for subsetting XML from SGML, and those responsible for dropping the ball by adding XML namespaces on top ;) aren't happy with it [1]. As to why URIs, I completely agree. I think URIs/URLs were introduced by TBL as arguably the major feat of HTML over generic SGML along with <a> and so phenomenally successful every W3C mechanism of name resolution and namespacing had to make use if it; RDF is littered with namespaces as well. [1]: https://blog.jclark.com/2010/01/xml-namespaces.html https://blog.jclark.com/2010/01/xml-namespaces.html

arethuza 3y ago
That's quite fascinating - shows how you can have a design process where every step is completely reasonable but the end-result can still be horrible!

andyjohnson0 3y ago

As you say, its piggybacking on the dns's uniqueness guarantee. Urls do at least provide and obvious way to have multiple namespaces per domain. But I agree that it's confusing. I once had the misfortune to have to use a third-party xml-based webservice whos developers thought that the xml namespace had to match the url used to access it. So their production and test systems had completely different namespaces. They maintained multiple xsd schemas for each system that only differed by namespace. When I finally managed to explain namespaces to their "chief web architect" he got all embarrassed. This was back in .net 4.x days, and I was generating serialisation classes from their schemas - so I had to create two different dlls and load the appropriate one at runtime. Very aggravating.

yrro 3y ago
good grief

Communitivity 3y ago

The W3C has all their specs, as far as I know, use Uniform Resource Identifiers (URIs), and most use the subset of Uniform Resource Locators (URLs). There seems to be a strong sentiment against using other types of identifiers, based on my experience on the Extensible Resource Identifier (XRI) technical committee in OASIS. So the chance that they'd create a new one for XPath was probably very unlikely, in my opinion. Even non-URL URIs might have been better for XPATH namespaces. As an aside, I haven't used XPath in a few years, but use JSONPath / JSONPointer on multiple days each week, and highly recommend them. I find XML to be great for many things, but I find JSON much easier to work with.

jerf 3y ago

The idea is that the URL can do something, like link to specification or something. However, there is nothing mandatory the URL has to do whatsoever. I think in practice you can treat it as an opaque blob and if you want to just declare a namespace as "bar.foo.example.com" I think it would work just about everywhere. There's enough legacy, but still in use, namespaces that aren't full legal URIs that libraries will never be able to start enforcing it, and since there's effectively no utility in forcing them to be URIs anyhow I doubt it'll suddenly become an issue when all the libraries decide to become compliant. Given that it's a bit bizarre to have a URI to something that doesn't have to even so much as exist, I can't see the standards bodies every getting very fussy about this either. Backing it down to just being "some agreed-upon blob value" would be backwards compatible anyhow.

arethuza 3y ago
"However, there is nothing mandatory the URL has to do whatsoever" To be honest I think that just added to the confusion - the idea of using a URI that was just a unique name and not something that actually referred to anything wasn't the easiest thing to appreciate.