5 ms·

A major pain point of using XPath in isolation (not embedded in XSLT or something else) is those damn namespace bindings. Ugly enough as xmlns: pseudo attribute

A major pain point of using XPath in isolation (not embedded in XSLT or something else) is those damn namespace bindings. Ugly enough as xmlns: pseudo attributes, in the absence of XML you'd have to use freaking XPointer bindings (as in "xmlns(bla=uri)//bla:xpathexpr/bla:following[@here]"), interpret HTML as XHTML with implicit namespaces, and similar tricks I thought HTML5 left behind for good. Bit surprised htmx falls into the XML nostalgia trap.

arethuza 3y ago
Namespaces always seemed to be the ugliest part of the XML ecosystem - I know why they were required, but they always seemed to be horrible to work with.
- 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.
- _y8kz 3y ago
  The worst thing is not the existence of namespaces, but that are are relatively often implemented incorrectly. As an example of things that sometimes break: * namespace redefinition: you have xmlns:ns1 on a parent node and xmlns:ns1 with different value on a child node. * same namespace on sibling nodes (happens often with streaming): multiple child nodes have a xmls:ns1 with some value. That is only valid for that node. * some processors expect namespaces only on a specific node (I think it was MS Navision ~ decade ago that failed when declaration wasn't on a specific node, but on a child node)
  - TheRealDunkirk 3y ago
    Indeed. There is an XML formatted file that is important to the engineers at my company. Sometimes they're namespaced; sometimes not, so just I remove the namespace if it's there. It wasn't like the people who defined the namespace gave us any usable format definition to work with anyway. The only thing worse than XML is an XML definition that's only half-implemented. raw = Nokogiri::XML(File.read(uploaded_file).gsub(/ xmlns="[^"]\*"/, "")) { |config| config.noblanks }
  - jerf 3y ago
    I am yet to see a system that uses namespaces 100% correctly, especially larger systems. XMPP is closest but they still have the stream tag defined as carrying a namespace, but as being the "same" stream tag without specifying it to be so, last I recall. The annoying thing is namespaces are not that complicated. They're probably five times more complicated than they need to be because you're always dealing with some library or system's half-assed bizarre implementation of them instead of the rather simple spec.
- vbezhenar 3y ago
  My biggest issue with XML namespaces is how they work with attribute names. I worked with XML enough but I have no idea how it really works. Every time I had to Google it or trial it. My opinion is that XML would be much better without attributes. A lot of things would be simpler. Attributes are nice, but they add whole another dimension of problems everywhere.
  - jerf 3y ago
    In an XML document using namespaces, all tags and attributes are named with the tuple (namespace, name). Tags are always in the empty string namespace unless an explicit namespace prefix is given, in which case the tag's namespace in the one corresponding to the prefix. That's it. That's all there is to namespaces and attributes. The idea is that the namespace would be redundant to the namespace on the tag, because the attribute's meaning is already 100% dependent on what tag it is on anyhow. The big key to working with namespace documents in general is you have to understand that the names are now tuples (namespace, name), and that the string prefix you may see like "ns1" is an abbreviation, not the namespace. The namespace is the thing declared as the attribute of the xmlns tag. Get that right and most of the rest follows. What almost everything gets wrong is failing to treat names as (namespace, name) correctly, and trying to treat names as a single string like in non-namespaced document, and then writing in whatever misconceptions their particular implementation wrote in to get around the fundamental impossibility of handling a 2-tuple with an internal datastructure that is only a 1-tuple.
    - cxr 3y ago
      > Tags are always in the empty string namespace unless an explicit namespace prefix is given, in which case the tag's namespace in the one corresponding to the prefix.¶ That's it. That's all there is to namespaces and attributes. This is at best misleading (or worse: misled—and wrong). The semantics of the following snippet is completely different: <foo:bar baz="xyzzy"/> ... from this: <foo:bar foo:baz="xyzzy"/> (Assume the "foo" prefix is defined and mapped to a namespace.) This is before even getting into the fact that unprefixed elements will belong to the default namespace (despite being written with no "explicit namespace prefix"). > The namespace is the thing declared as the attribute of the xmlns tag. The "xmlns tag"? No.
- marcosdumay 3y ago
  > I know why they were required Have you ever seen tag name clashing in a XML document?
  - arethuza 3y ago
    I can vaguely remember working on systems in the finance industry that combined vendor XML, various internal XML schemas and transformed these into XSL-FO documents for rendering through multiple passes through XSLT. If I had to guess the chances of there being some element names clashing without namespaces would have been fairly high.
listenallyall 3y ago
> Bit surprised htmx falls into the XML nostalgia trap. As the article states, the only tag that can't be searched for via CSS selectors is the new "hx-on". And my initial thought about this is (which I'm open to reconsider), it seems like you probably shouldn't go looking for elements based on their event model. Show me every <div> with a certain value in its class attribute? Yes of course. But find me every <div> with a certain behavior on mouseUp? This isn't something you'd do in an OO language, you'd look for objects with a certain property value, not a specific event handler, which would likely be private anyway. I'd also note that, for the same reason, standard HTML as well as React, etc have the same inability as HTMX here. The article notes that with HTMX you can't use CSS selectors to find "hx-on(something)" tags, the same handicap prevents you from searching for any element with an "on(something)" attribute, i.e. onClick, onMouseUp, onKeyPress etc. Maybe I haven't thought through this entirely but I don't see any problem here. (edit: to be clear, of course you can CSS-select a specific tag like onClick, and you can also select a specific HTMX tag like hx-on:click. What the article notes that you cannot do is search via wildcards or "starts-with" in CSS, i.e. hx-on:*, but you can't do on* either)
kjhughes 3y ago
A common source of frustration is that XPath itself doesn't provide a means of binding a namespace prefix with a namespace. It relies upon mechanisms provided by the hosting language or library. After helping scores of devs with such problems on Stack Overflow, I took time to write a canonical answer addressing this issue: How does XPath deal with XML namespaces? https://stackoverflow.com/a/40796315/290085 https://stackoverflow.com/a/40796315/290085

arethuza 3y ago

Namespaces always seemed to be the ugliest part of the XML ecosystem - I know why they were required, but they always seemed to be horrible to work with.

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.
_y8kz 3y ago
The worst thing is not the existence of namespaces, but that are are relatively often implemented incorrectly. As an example of things that sometimes break: * namespace redefinition: you have xmlns:ns1 on a parent node and xmlns:ns1 with different value on a child node. * same namespace on sibling nodes (happens often with streaming): multiple child nodes have a xmls:ns1 with some value. That is only valid for that node. * some processors expect namespaces only on a specific node (I think it was MS Navision ~ decade ago that failed when declaration wasn't on a specific node, but on a child node)
- TheRealDunkirk 3y ago
  Indeed. There is an XML formatted file that is important to the engineers at my company. Sometimes they're namespaced; sometimes not, so just I remove the namespace if it's there. It wasn't like the people who defined the namespace gave us any usable format definition to work with anyway. The only thing worse than XML is an XML definition that's only half-implemented. raw = Nokogiri::XML(File.read(uploaded_file).gsub(/ xmlns="[^"]\*"/, "")) { |config| config.noblanks }
- jerf 3y ago
  I am yet to see a system that uses namespaces 100% correctly, especially larger systems. XMPP is closest but they still have the stream tag defined as carrying a namespace, but as being the "same" stream tag without specifying it to be so, last I recall. The annoying thing is namespaces are not that complicated. They're probably five times more complicated than they need to be because you're always dealing with some library or system's half-assed bizarre implementation of them instead of the rather simple spec.
vbezhenar 3y ago
My biggest issue with XML namespaces is how they work with attribute names. I worked with XML enough but I have no idea how it really works. Every time I had to Google it or trial it. My opinion is that XML would be much better without attributes. A lot of things would be simpler. Attributes are nice, but they add whole another dimension of problems everywhere.
- jerf 3y ago
  In an XML document using namespaces, all tags and attributes are named with the tuple (namespace, name). Tags are always in the empty string namespace unless an explicit namespace prefix is given, in which case the tag's namespace in the one corresponding to the prefix. That's it. That's all there is to namespaces and attributes. The idea is that the namespace would be redundant to the namespace on the tag, because the attribute's meaning is already 100% dependent on what tag it is on anyhow. The big key to working with namespace documents in general is you have to understand that the names are now tuples (namespace, name), and that the string prefix you may see like "ns1" is an abbreviation, not the namespace. The namespace is the thing declared as the attribute of the xmlns tag. Get that right and most of the rest follows. What almost everything gets wrong is failing to treat names as (namespace, name) correctly, and trying to treat names as a single string like in non-namespaced document, and then writing in whatever misconceptions their particular implementation wrote in to get around the fundamental impossibility of handling a 2-tuple with an internal datastructure that is only a 1-tuple.
  - cxr 3y ago
    > Tags are always in the empty string namespace unless an explicit namespace prefix is given, in which case the tag's namespace in the one corresponding to the prefix.¶ That's it. That's all there is to namespaces and attributes. This is at best misleading (or worse: misled—and wrong). The semantics of the following snippet is completely different: <foo:bar baz="xyzzy"/> ... from this: <foo:bar foo:baz="xyzzy"/> (Assume the "foo" prefix is defined and mapped to a namespace.) This is before even getting into the fact that unprefixed elements will belong to the default namespace (despite being written with no "explicit namespace prefix"). > The namespace is the thing declared as the attribute of the xmlns tag. The "xmlns tag"? No.
marcosdumay 3y ago
> I know why they were required Have you ever seen tag name clashing in a XML document?
- arethuza 3y ago
  I can vaguely remember working on systems in the finance industry that combined vendor XML, various internal XML schemas and transformed these into XSL-FO documents for rendering through multiple passes through XSLT. If I had to guess the chances of there being some element names clashing without namespaces would have been fairly high.

listenallyall 3y ago

> Bit surprised htmx falls into the XML nostalgia trap. As the article states, the only tag that can't be searched for via CSS selectors is the new "hx-on". And my initial thought about this is (which I'm open to reconsider), it seems like you probably shouldn't go looking for elements based on their event model. Show me every <div> with a certain value in its class attribute? Yes of course. But find me every <div> with a certain behavior on mouseUp? This isn't something you'd do in an OO language, you'd look for objects with a certain property value, not a specific event handler, which would likely be private anyway. I'd also note that, for the same reason, standard HTML as well as React, etc have the same inability as HTMX here. The article notes that with HTMX you can't use CSS selectors to find "hx-on(something)" tags, the same handicap prevents you from searching for any element with an "on(something)" attribute, i.e. onClick, onMouseUp, onKeyPress etc. Maybe I haven't thought through this entirely but I don't see any problem here. (edit: to be clear, of course you can CSS-select a specific tag like onClick, and you can also select a specific HTMX tag like hx-on:click. What the article notes that you cannot do is search via wildcards or "starts-with" in CSS, i.e. hx-on:*, but you can't do on* either)

kjhughes 3y ago

A common source of frustration is that XPath itself doesn't provide a means of binding a namespace prefix with a namespace. It relies upon mechanisms provided by the hosting language or library. After helping scores of devs with such problems on Stack Overflow, I took time to write a canonical answer addressing this issue: How does XPath deal with XML namespaces? https://stackoverflow.com/a/40796315/290085 https://stackoverflow.com/a/40796315/290085