Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xee: A Modern XPath and XSLT Engine in Rust

blog.startifact.com

Post reply on HN
Print view View original

111–120 of 245 posts

Re: Xee: A Modern XPath and XSLT Engine in Rust

#111

Post by faassen »

kgwxd wrote: post #49
mickeyp wrote: post #10

It's interesting to see the slow rehabilitation of XML and its tooling now that there's a new generation of developers who have not grown up in the shadow of XML's prime in the late 90s / early 2000s, and who have not heard (or did not buy into) the anti-XML crowd's ranting --- even though some of their criticisms were legitimate. I've always liked XML, and especially XPath, and even though there were a large number…

XML, and other X[x] standards, are just horrible to read. On top of that, XML was made 10x worse by wrapping things in SOAP and the like over the wire, back in the day. XSD, XPath, XSLT are all domains where I'd argue that reading/reasoning about are way more important. When troubleshooting an issue, I don't mind scanning XML for a few data points so I can confirm what values are being communicated, but when I need t…

The specifications are certainly not easy to read, and I wouldn't recommend them to learn about XML. But from the perspective of someone implementing them they are quite useful!

As someone who has used many programming languages and who went through the process of implementing this one I have many opinions about XPath and XSLT as programming languages. I myself am more interested in implementing them for others who value using them than using them myself. I do recognize there is a sizeable community of people who do use these tools and are passionate about them - and that's interesting to see and more power to them!

Re: Xee: A Modern XPath and XSLT Engine in Rust

#112

Post by jerf »

infogulch wrote: post #26

There are many humongous XML sources. E.g. the Wikipedia archive is 42GB of uncompressed text. Holding a fully parsed representation of it in memory would take even more, perhaps even >100GB which immediately puts this size of document out of reach. The obvious solution is streaming, but streaming appears to not be supported, though is listed under Challenging Future Ideas: https://github.com/Paligo/xee/blob/main/ide…

"How hard is it to implement XML/XSLT/XPATH streaming?"

It's actually quite annoying on the general case. It is completely possible to write an XPath expression that says to match a super early tag on an arbitrarily-distant further tag.

In another post in this thread I mention how I think it's better to think of it as a multicursor, and this is part of why. XPath doesn't limit itself to just "descending", you can freely cursor up and down in the document as you write your expression.

So it is easy to write expressions where you literally can't match the first tag, or be sure you shouldn't return it, until the whole document has been parsed.

Re: Xee: A Modern XPath and XSLT Engine in Rust

#115

Post by eyelidlessness »

montroser wrote: post #3

Fun fact: XSLT still enjoys broad support across all major browsers: https://caniuse.com/?search=xslt

I can’t say this with certainty, but I have some reason to suspect I might be partially to blame for this fun fact!

A couple years ago, I stumbled on a discussion considering deprecation/removal of XSLT support in Chrome. At some point in the discussion, they mentioned observing a notable uptick in usage—enough of an uptick (from a baseline of approximately zero) that they backed out.

The timing was closely correlated with work I’d done to adapt a library, which originally used XSLT via native Node extensions, to browser XSLT APIs. The project isn’t especially “popular” in the colloquial sense of the term, but it does have a substantial niche user base. I’m not sure how much uptake the browser adaptation of this library has had since, but some quick napkin math suggested it was at least plausible that the uptick in usage they saw might have been the onslaught of automated testing I used to validate the change while I was working on it.

Re: Xee: A Modern XPath and XSLT Engine in Rust

#116

Post by shawn_w »

zoogeny wrote: post #104
velcrovan wrote: post #67

Earlier quoted context omitted.

You should try using a LISP like Racket for XML. Because XML can be expressed directly as S-expressions, XML and LISP go together like peanut butter and jelly. Hello world (greeting ((attr "val") (href "#")) "Hello " (thing "world"))

This looks like it loses the distinction between attributes and nested tags? As in, I don't see a difference between `(attr "val")` which expresses an attribute key/value pair and `(thing "world")` which expresses a tag/content relationship. Even if I thought the rule might be "if the first element of the list is a list itself then it should be interpreted as a set of attribute key value pairs" then I would still be…

There's no ambiguity. The first element is a symbol that's the name of a tag. If the second element is a list of two element symbol + string lists, it's the attributes. If it's one of the other recognized types, it's part of the contents of the tag.

See a grammar for the representation at https://docs.racket-lang.org/xml/index.html#%28def._%28%28li...

Most Scheme tools for working with XML use a different layout where a list starting with the symbol @ indicates attributes. See https://en.wikipedia.org/wiki/SXML for it.

Re: Xee: A Modern XPath and XSLT Engine in Rust

#117

Post by tonyedgecombe »

wiremine wrote: post #95
vessenes wrote: post #13

This, thirty years later, is the best pitch for XML I’ve read. Essentially, it’s a slow moving, standards-based approach to data interoperability. I hated it the minute I learned about it, because it missed something I knew I cared about, but didn’t have a word for in the 90s - developer ergonomics. XML sucks shit for someone who wants to think tersely and code by hand. Seriously, I hate it with a fiery passion. Happ…

> developer ergonomics That was a huge reason JSON took over. Another reason was the overall XML ecosystem grew unwieldy and difficult to navigate: XPath, XSLT, SOAP, WSDL, Xpointer, XLink, SOAP, XForms... They all made sense in their own way, but it was difficult to master them all. That complexity, plus the poor ergonomics, is what paved the way for JSON to become preferred.

I quite liked it when it first came out, I'd been dealing with a ton of bespoke formats up until then. Pretty much every one was ambiguous and painful to deal with. It was a step forward being able to push people towards a standard for document transfer.

I suspect it was SOAP and WSDL that killed it for a lot of people though. That was a typical example of a technical solution looking for a problem and complete overkill for most people.

The whole namespace thing was probably a step too far as well.

Re: Xee: A Modern XPath and XSLT Engine in Rust

#118

Post by kibwen »

vessenes wrote: post #13

This, thirty years later, is the best pitch for XML I’ve read. Essentially, it’s a slow moving, standards-based approach to data interoperability. I hated it the minute I learned about it, because it missed something I knew I cared about, but didn’t have a word for in the 90s - developer ergonomics. XML sucks shit for someone who wants to think tersely and code by hand. Seriously, I hate it with a fiery passion. Happ…

> XML sucks shit for someone who wants to think tersely and code by hand. Seriously, I hate it with a fiery passion.

At the risk of glibly missing the main point of your comment, take a look at KDL. Unlike JSON/TOML/YAML, it features XML-style node semantics. Unlike XML, it's intended to be human-readable and writeable by hand. It has specifications for both a query language and a schema language as well as implementations in a bunch of languages. https://kdl.dev/

Re: Xee: A Modern XPath and XSLT Engine in Rust

#119

Post by masklinn »

ebruchez wrote: post #81
samsk wrote: post #21

Nice ! I've a scrapper using XPath/XSLT extensively and 90% of the XPath selectors work like for years without a change. With CSS selectors I've had more problems...

CSS selectors have spent the last few decades reinventing XPath. XPath introduced right from the beginning the notion of axes, which allow you to navigate down, up, preceding, following, etc. as makes sense. XPath also always had predicates, even in version 1.0. CSS just recently started supporting :has() and :is(), in particular. Eventually, CSS selectors will match XPath's query abilities, although with worse synta…

On the other hand:

- XPath literally didn't exist when CSS selectors were introduced

- XPath's flexibility makes it a lot more challenging to implement efficiently, even more so when there are thousands of rules which need to be dynamically reevaluated at each document update

- XPath is lacking conveniences dedicated to HTML semantics, and handrolling them in xpath 1.0 was absolutely heinous (go try and implement a class predicate in xpath 1.0 without extensions)

Re: Xee: A Modern XPath and XSLT Engine in Rust

#120

Post by masklinn »

bambax wrote: post #86
ebruchez wrote: post #81

Earlier quoted context omitted.

CSS selectors have spent the last few decades reinventing XPath. XPath introduced right from the beginning the notion of axes, which allow you to navigate down, up, preceding, following, etc. as makes sense. XPath also always had predicates, even in version 1.0. CSS just recently started supporting :has() and :is(), in particular. Eventually, CSS selectors will match XPath's query abilities, although with worse synta…

> CSS selectors have spent the last few decades reinventing XPath YES! This is so true! And ridiculous! It's a mystery why we didn't simply reuse XPath for selectors... it's all in there!!

> It's a mystery why we didn't simply reuse XPath for selectors... it's all in there!!

It's not really a mystery:

> CSS was first proposed by Håkon Wium Lie on 10 October 1994. [...] discussions on public mailing lists and inside World Wide Web Consortium resulted in the first W3C CSS Recommendation (CSS1) being released in 1996

> XPath 1.0 was published in 1999

CSS2 was released before XPath 1.0.

Post reply on HN