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

121–130 of 245 posts

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

#121

Post by riedel »

jerf wrote: post #112
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 fre…

I think from a grammar side, XPath had made some decisions that make it really hard to generally implement it efficiently. About 10 years ago I was looking into binary XML systems and compiling stuff down for embedded systems realizing that it is really hard to e.g. create efficient transducers (in/out pushdown automata) for XSLT due to complexity of XPath.

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

#123

Post by ajxs »

montroser wrote: post #3

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

Being interested in archaic technologies, I built a website using XML/XSLT not that long ago. The site was an archive of a band I was in, which made it fundamentally data oriented: We recorded multiple albums, with different tracks, and a different lineup of musicians each time. There's lots of different databases I could built a static site generator around, but what if the browser could render the page straight from the data? That's what's cool about XML/XSLT. On paper, I think it's actually a pretty nice idea: The browser starts by loading the actual data, and then renders it into HTML according to a specific stylesheet. Obviously the history of browser tech forked in a different direction, but the idea remains good. What if there was native browser support for styling JSON into HTML?

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

#124

Post by riedel »

Love to see stuff outside the Java space since I really like thedoing stuff in XSLT. Question: Does this work on a textual XML representation or can you plug in different XML readers? I have had really great fun in the past using http://www.ananas.org/xi/ transforming arbitrarily for formated files using XSLT. Also it is today really important that XML Reader has error correction capabilities, since lots of tools don't write well-formed XML, which often is a showstopper for employing to transforms from my experience.

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

#125

Post by smartmic »

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 implemented XPath/XQuery 3.1 perfectly for my requirements. Another insider tip is that XPath/XQuery 3.1 can also be used to transform JSON wonderfully - JSONiq is therefore obsolete.

[1] https://www.videlibri.de/xidel.html

[2] https://github.com/benibela/xidel

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

#126

Post by madkangas »

iamthepieman wrote: post #85
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 try…

Re xslt based web applications - a team at my employer did the same circa 2004. It worked beautifully except for one issue: inefficiency. The qps that the app could serve was laughable because each page request went through the xslt engine more than once. No amount of tuning could fix this design flaw, and the project was killed.

Names withheld to protect the guilty. :)

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

#127

Post by kondro »

blacklion wrote: post #122

Does XSLT still used in a new projects? I have impression, that it was not popular even when XML was. For example, apache HTTPD never has official module to serve XML via XSLT transformation. And XSL:FO looks even more obscure.

There are a lot of APIs out there that are still XML-based, especially from enterprise suppliers.

Equifax and Experian’s APis immediately come to mind as documents that generate complex results that people often want to turn into some type of visual representation with XSLT.

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

#128

Post by smartmic »

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…

Forget to add, for latest XQuery up to 4.0, there is also BaseX [1] — this time a Java program. It has a great GUI/IDE for XQuery rapid prototyping.

[1] https://basex.org/basex/xquery/

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

#129

Post by lambda »

faassen wrote: post #64
infogulch wrote: post #58

Earlier quoted context omitted.

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!

I myself actually had no idea succinct data structures existed until last December , but then I found a paper that used them in the context of XML. Just to be clear: it's 120% of the original size; as it stands this library still uses more memory than the original document, just not a lot of overhead. Normal tree libraries, even if the tree is immutable, take a parent pointer, and a first child pointer and next and p…

Would you be able to parse it in a streaming fashion and just store the structure of the document in memory, with just offsets for all of the string locations, and then re-read those from disk as needed?

With modern SSDs and disk cache, that's likely enough to be plenty performant without having to store the whole document in memory at once.

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

#130

Post by miki123211 »

sramsay wrote: post #102
Finnucane wrote: post #74

Earlier quoted context omitted.

I've worked on archive projects with complex TEI xml files (which is why when people say xml is bad and it should be all json or whatever, I just LOL), and fortunately, my employer will pay for me to have an editor (Oxygen) that includes the enterprise version of Saxon and other goodies. An open-source xml processing engine that wasn't decades out of date would be a big deal in the digital humanities world.

I don't think people realize just how important XML is in this space (complex documentary editing, textual criticism, scholarly full-text archives in the humanities). JSON cannot be used for the kinds of tasks to which TEI is put. It's not even an option. Nothing could compel me to like XSLT. I admire certain elements of its design, but in practice, it just seems needlessly verbose. But I really love XPath, though.

XML is great for documents.

If your data is essentially a long piece of text, with annotations associated with certain parts of that text, this is where XML shines.

When you try to use XML to represent something like an ecommerce order, financial transaction, instant message and so on, this is where you start to see problems. Trying to shove some extremely convoluted representation of text ranges and their attributes into JSON is just as bad.

A good "rule of thumb" would be "does this document still make sense if all the tags are stripped, and only the text nodes remain?" If yes, choose XML, if not, choose JSON.

Post reply on HN