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

81–90 of 245 posts

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

#81

Post by ebruchez »

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

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

#82

Post by ebruchez »

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…

There have been proposals a long time ago, including by Tim Bray, for an XML 2.0 that would remove some warts. But there was no appetite in the industry to move forward.

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

#83

Post by Devasta »

airstrike wrote: post #8

What problems are {elegantly, neatly, best} solved by using XPath and XSLT today that would make them reasonable choices over alternatives?

I manage a team who build and maintain trading data reports for brokers, we have everything generate in a fairly standard format and customize to those brokers exact needs with XSLT. Hundreds of reports, couldnt manage without it.

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

#84

Post by bambax »

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…

I used to do a lot of XSLT coding, by hand, in text editors that weren't proper IDEs, and frankly it wasn't very hard to do.

There's something very zen-like with this language; you put a document in a kind of sieve and out comes a "better" document. It cannot fail; it can be wrong, full of errors, of course (although if you're validating the result against a schema it cannot be very wrong); but it will almost never explode in your face.

And then XSLT work kind of disappeared; I miss it a lot.

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

#85

Post by iamthepieman »

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 has always seemed to be a data standard which is intended to be what computers prefer, not people

Interesting take, but I'm always a little hesitant to accept any anthropomorphizing of computer systems.

Isn't it always about what we can reason and extrapolate about what the computer is doing? Obviously computers have no preference so it seems like you're really saying

"XML is a poor abstraction for what it's trying to accomplish" or something like that.

Before jQuery, chrome, and web 2.0, I was building xslt driven web pages that transformed XML in an early nosql doc store into html and it worked quite beautifully and allowed us to skip a lot of schema work that we definitely were ready or knowledgeable enough to do.

EDIT: It was the perfect abstraction and tool for that job. However the application was very niche and I've never found a person or team who did anything similar (and never had the opportunity to do anything similar myself again)

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

#86

Post by bambax »

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…

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

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

#87

Post by samsk »

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…

The problem with CSS selectors (at least in scrapers) is also that they change relatively often, compared to (html) document structure, thats why XPath last longer. But you are right, CSS selectors compared to 20 years old XPath are realy worse.

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

#88

Post by bambax »

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…

> Elements are for data. Attributes are evil

This is like, your opinion, man... ;-) You can devise your schema any way you want. Attributes are great, and they exist in HTML in the form of datasets, which, as usual, are a poorly-specified and ill-designed rethinking of XML attributes

> Documents without a schema should not make your tools panic or complain

They don't. You absolutely don't need a schema. If you declare a schema, it should exist. If not, no problem?

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

#89

Post by Locutus_ »

4ndrewl wrote: post #60
formerly_proven wrote: post #33

Earlier quoted context omitted.

Working with large YAML documents is incredibly annoying and shows the benefit of closing tags.

It all went downhill after we stopped using .ini files

Well....toml isn't that much more than .ini files slightly brough up in feature support.

Again not great for bigger documents.

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

#90

Post by Mountain_Skies »

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…

Microsoft seems to be especially obsessed with making as much as possible into attributes. Makes me wonder if there is some hidden historical reason for that like an especially powerful evangelist inside the company that loved attributes during the early days of adopting XML.
Post reply on HN