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

51–60 of 245 posts

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

#51

Post by tannhaeuser »

falcor84 wrote: post #12
Telemakhos wrote: post #9

Earlier quoted context omitted.

This is true only of XSLT 1.0. The current standard is 3.0.

Oh, a shame. Is there any way to track browser version adoption on caniuse, or any other site? Also, is it up to browser implementations, or does WHATWG expect browsers to stay at version XSLT 1?

There's nothing to track here really. For better or worse, browsers are stuck with 1999's XSLT 1.0, and it's a miracle it's still part of native browser stacks given PDF rendering has been implemented using JS for well over a decade now.

XSLT 2 and 3 is a W3C standard written by the sole commercial provider of an XSLT 2 or 3 processor, which is problematic not only because it reduces W3C to a moniker for pushing sales, but also because it undermines W3C's own policy of at least two interworking implementations for a spec to get "recommendation" status.

XSLT is of course a competent language for manipulating XML. It would be a good fit if your processing requires lots of XML literals/fragments to be copied into your target document since XSLT is an XML language itself. Though OTOH it uses XPath embedded in strings excessively, thereby distrusting XML syntax for a core part of its language itself, and coding XPath in XML attributes can be awkward due to restrictive contextual encoding rules for special characters and such.

XSLT can be a maintenance burden if used casually/rarely, since revisiting XSLT requires substantial relearning and time investment due to its somewhat idiosyncratic nature. IDE support for discovery, refactoring, and test automation etc. is lacking.

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

#52

Post by faassen »

mattrighetti wrote: post #24

I will definitely try this out! I have a service that extracts tags in webpages and to do that I'm currently using (and need) three different dependencies: html5ever, markup5ever_rcdom, markup5ever. I don't like those to be honest, the documentation is quite bad and it was difficult to understand how I should have used the libraries to achieve such a simple task. XPath on the other hand makes this extremely easy in c…

Thanks!

Unfortunately at this point there's no HTML parser frontend for Xee (and its underlying library Xot) yet (HTML 5 parser serialization is supported at least in code). It shouldn't be too hard to add at least HTML 5 support using something like html5ever.

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

#53

Post by infogulch »

wongarsu wrote: post #31
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…

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 reasonable floor for every person that wants to mess with big xml files.

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

#54

Post by [deleted] »

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…

[deleted]

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

#57

Post by da_chicken »

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 reasons JSON got so popular so quickly is because it does all of the above. The problem with JSON is that you lose the benefits of having a schema to validate against.

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

#58

Post by infogulch »

faassen wrote: post #50
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…

Anything could be supported with sufficient effort, but streaming hasn't been my priority so far and I haven't explored it in detail. I want to get XSLT 3.0 working properly first. There's a potential alternative to streaming, though - succinct storage of XML in memory: https://blog.startifact.com/posts/succinct/ I've built a succinct XML library named Xoz (not integrated into Xee yet): https://github.com/Paligo/xoz…

0.2x of the original size would certainly make big documents more accessible. I've heard of succinct storage, but not in the context of xml before, thanks for sharing!

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

#59

Post by hyhjtgh »

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…

Xml and textual formats in general are ill suited to such large documents. Step 1 should really be to convert and/or split the file into smaller parts.

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

#60

Post by 4ndrewl »

formerly_proven wrote: post #33
tzcnt wrote: post #19

Earlier quoted context omitted.

Developer ergonomics is drastically underappreciated, even in modern times. Since we're talking about textual data formats, I'll go out on a limb here and say that I hate YAML. Double checking exactly how many spaces are present on each line is tedious. It manages to make a simple task like copy-pasting something from a different file (at a different indentation level) into an error-prone process. I'll take angle bra…

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
Post reply on HN