←back to thread

XSLT – Native, zero-config build system for the Web

(github.com)
392 points _kush | 7 comments | 27 Jun 25 05:00 UTC | HN request time: 1.082s | source | bottom
Show context
CiaranMcNulty ◴[27 Jun 25 06:41 UTC] No.44394259[source]▶
It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats.

I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like `<xsl:include href="mycorp://invoice/1234">`

This may be out-of-date bias but I'm still a little uneasy letting the browser do the locally, just because it used to be a minefield of incompatibility

replies(8): >>44394503 #>>44394794 #>>44395004 #>>44395249 #>>44395303 #>>44396380 #>>44398418 #>>44399777 #
1. codeulike ◴[27 Jun 25 07:26 UTC] No.44394503[source]▶
Xpath would have been nice if you didnt have to pedantically namespace every bit of every query
replies(2): >>44394910 #>>44402159 #
2. masklinn ◴[27 Jun 25 08:26 UTC] No.44394910[source]▶
That… has nothing to do with xpath?

If your document has namespaces, xpath has to reflect that. You can either tank it or explicitly ignore namespaces by foregoing the shorthands and checking `local-name()`.

replies(1): >>44395654 #
3. codeulike ◴[27 Jun 25 10:41 UTC] No.44395654[source]▶
Ok. Perhaps 'namespace the query' wasnt quite the right way of explaining it. All I'm saying is, whenever I've used xpath, instead of it looking nice like

/*bookstore/*book/*title

its been some godawful mess like

/*[name()='bookstore']/*[name()='book']/*[name()='title']

... I guess because they couldn't bear to have it just match on tags as they are in the file and it had to be tethered to some namespace stuff that most people dont bother with. A lot of XML is ad-hoc without a namespace defined anywhere

Its like

Me: Hello Xpath, heres an XML document, please find all the bookstore/book/title tags

Xpath: *gasps* Sir, I couldn't possibly look for those tags unless you tell me which namespace we are in. Are you some sort of deviant?

Me: oh ffs *googles xpath name() syntax*

replies(3): >>44396064 #>>44396175 #>>44396245 #
4. rhdunn ◴[27 Jun 25 11:57 UTC] No.44396064{3}[source]▶
Newer versions of XPath and XSLT allow

    /*:bookstore/*:book/*:title
5. ndriscoll ◴[27 Jun 25 12:14 UTC] No.44396175{3}[source]▶
I don't recall ever needing to do that for unnamespaced tags. Are you sure the issue you're having isn't that the tags have a namespace?

my:book is a different thing from your:book and you generally don't want to accidentally match on both. Keeping them separate is the entire point of namespaces. Same as in any programming language.

6. masklinn ◴[27 Jun 25 12:22 UTC] No.44396245{3}[source]▶
> the tags as they are in the file

Is not actually relevant and is not an information the average XML processor even receives. If the file uses a default namespace (xmlns), then the elements are namespaced, and anything processing the XML has to either properly handle namespaces or explicitly ignore namespaces.

> A lot of XML is ad-hoc without a namespace defined anywhere

If the element is not namespaced xpath does not require a prefix, you just write

    //bookstore/book/title
7. somat ◴[28 Jun 25 03:39 UTC] No.44402159[source]▶
Can confirm, Working programaticly with XML is not really that bad, there is a well formed query syntax(xpath), the dom api just works.

Until some joker decided to employ xml namespaces, then everything turns ugly real fast. I am not sure I can articulate why it is so unpleasant, something about how everything gets super verbose and api now needs all sorts of extra state.