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

141–150 of 245 posts

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

#141

Post by nicoburns »

infogulch wrote: post #53
wongarsu wrote: post #31

Earlier quoted context omitted.

100GB doesn't sound that out of reach. It's expensive in a laptop, but in a desktop that's about $300 of RAM and our supported by many consumer mainboards. Hetzner will rent me a dedicated server with that amount of ram for $61/month. If the payloads in question are in that range, the time spent to support streaming doesn't feel justified compared to just using a machine with more memory. Maybe reducing the size of t…

I just pulled the 100GB number out of nowhere, I have no idea how much overhead parsed xml consumes, it could be less or it could be more than 2.5x (it probably depends on the specific document in question). In any case I don't have $1500 to blow on a new computer with 100GB of ram in the unsubstantiated hope that it happens to fit, just so I can play with the Wikipedia data dump. And I don't think that's a reasonabl…

Shouldn't parsed XML be smaller than the raw uncompressed text? (as you could deduplicate strings). I'd expect that to be a significant saving for something like wikipedia in XML

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

#143

Post by immibis »

caspper69 wrote: post #110
IgorPartola wrote: post #91

Earlier quoted context omitted.

That’s a flame war that’s been raging for decades for sure. I do wonder what web application markup would look like today if designed from scratch. It is kind of amazing that HTML and CSS can be used for creating beautiful documents viewable on pretty much any device with a screen AND also for creating dynamic applications with pixel-perfect rendering, special effects, integrations with the device’s hardware, and eve…

Had we had better process isolation in the mid-90s, I assume web application development would mostly be Java apps, with a mini-vm for each one (sort of a qubes like environment). We just couldn't keeps apps' hands out of the cookie jar back then.

Java tried to, and mostly successfully did, run trusted and untrusted code in the same VM. Your applet code ran in the same VM as all the code for managing applets. However, holes were frequent enough that they abandoned the whole idea. (Instead of sandboxing the VM as a whole? Why?)

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

#144

Post by immibis »

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…

> In fact, this ambiguity between attributes and children has always been one of the head scratching things for me about XML. Well, the thing I've always disliked the most is namespaces but that is another matter.

Just remember that it's a markup language, and then it's not head-scratching at all: the text is the text being marked up, and the attribute values are the attribute of the markup - things like colour and font.

When it was co-opted to store structured data, those people didn't obey this rule (which would make everything attributes).

Namespaces had a very cool use in XHTML: you could just embed an SVG or MathML directly in your HTML and the browser would render it. This feature was copied into HTML5.

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

#145

Post by immibis »

da_chicken wrote: post #57
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…

My complaints about XML remain pretty much unchanged since 10 years ago. - Not including self-closing tags, there should only be one close tag: - Elements are for data. Attributes are evil - XPath indexing should be 0-based - Documents without a schema should not make your tools panic or complain - An xml document shouldn't have to waste it's time telling you it's an xml document in xml I maintain that one of the rea…

So how do I specify the font of a word without attributes?

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

#146

Post by philipkglass »

nicoburns wrote: post #141
infogulch wrote: post #53

Earlier quoted context omitted.

I just pulled the 100GB number out of nowhere, I have no idea how much overhead parsed xml consumes, it could be less or it could be more than 2.5x (it probably depends on the specific document in question). In any case I don't have $1500 to blow on a new computer with 100GB of ram in the unsubstantiated hope that it happens to fit, just so I can play with the Wikipedia data dump. And I don't think that's a reasonabl…

Shouldn't parsed XML be smaller than the raw uncompressed text? (as you could deduplicate strings). I'd expect that to be a significant saving for something like wikipedia in XML

For Wikipedia, the bulk of the data in the XML is inside a "" block that contains wikitext: https://en.wikipedia.org/wiki/Help:Wikitext

In the English Wikipedia the wikitext accounts for about 80% of the bytes of the decompressed XML dump.

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

#147

Post by o_pax »

This is really good news, I am looking forward to trying it out! Is XQuery also planned as an additional frontend? By the way, there is also χrust, a rust project working towards pretty similar goals (XPath 3.1, XQuery 3.1 and XSLT 3.0). At first glance, the architecture also seems quite similar, it is not as far along, though. Have you had any contact with them?

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

#148

Post by ebruchez »

masklinn wrote: post #120
bambax wrote: post #86

Earlier quoted context omitted.

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

Fair enough. By the way, the original CSS from 1996 featured only:

- the "descendant" combinator (whitespace) - the "class" selector (".foo")

The 1998 CSS2 introduced "child", "following sibling", and attribute selectors. This state of things then remained unchanged forever (I see that Selectors Level 3 became a recommendation only in 2018?).

On the other hand, in 1999, XPath already specified all those basic ways to navigate the DOM, and CSS still doesn't have them all as of 2025.

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

#149

Post by Devasta »

IgorPartola wrote: post #91
tannhaeuser wrote: post #28

Earlier quoted context omitted.

> XML has always seemed to be a data standard which is intended to be what computers prefer, not people. On one hand, you aren't wrong: XML has in fact been used for machine-to-machine communication mostly. OTOH, XML was just introduced as a subset of SGML doing away with the need of vocabulary-specific markup declarations for mere parsing in favor of always requiring explicit start- and end-element tags. Whereas HTM…

That’s a flame war that’s been raging for decades for sure. I do wonder what web application markup would look like today if designed from scratch. It is kind of amazing that HTML and CSS can be used for creating beautiful documents viewable on pretty much any device with a screen AND also for creating dynamic applications with pixel-perfect rendering, special effects, integrations with the device’s hardware, and eve…

If a browser was designed from scratch today it wouldn't have a markup language, documents would be PDF and everything else would be Javascript to canvas.

Suggesting something like HTML would have you laughed out of the room.

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

#150

Post by therealmarv »

smartmic wrote: post #125
therealmarv wrote: post #5

Great to see that somebody else creates a true open source XSLT 3 and XPATH 3 implementation! I worked on projects which refused to use anything more modern than XSLT & XPATH 1.0 because of lack of support in the non Java/Net World (1.0 = tech from 1999). Kudos to Saxon though, it was and is great but I wished there were more implementations of XSLT 2.0 & XPATH 2.0 and beyond in the open source World... both are so m…

Well, it's not as if this is the first free alternative. Here is a wonderful, incredibly powerful tool, not written in Java, but in Free Pascal, which is probably too often underestimated: Xidel[1]. Just have a look at the features and check its Github page[2]. I've often been amazed at its capabilities and, apart from web scraping, I mainly use it for XQuery executions - so far the latest version 0.9.9 has also impl…

interesting, did not know about that one! Thanks. (Small) but XSLT is not covered by it which is my main usage of XPATH unfortunately.

I will do some experiments with using newer XPATH on JSON... that could be interesting.

Post reply on HN