Live data from Hacker News

Xee: A Modern XPath and XSLT Engine in Rust

blog.startifact.com

181–190 of 245 posts

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

#181

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…

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.

If it were designed from scratch by BigTech anyway. Rather than JS I'd guess it would be WASM with APIs for canvas and accessibility. JS would go via WASM just like any other language you might prefer. If you asked about HTML you'd get pointed at the relevant render-to-canvas library in the language of your choice.

This is only the case because the BigTech view is one of an application platform.

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

#182

Earlier quoted context omitted.

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/

We also use BaseX to write restful backends with RestXQ - https://docs.basex.org/12/RESTXQ - the documentation itself is written in XQuery as well and uses a BaseX database as a source.

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

#183
post #62

Earlier quoted context omitted.

XML is a big improvement over YAML. There, I said it.

YAML is great. For simple configuration files. For anything more complex it gets gnarly quick, but honestly? If I need a config file for a script I'm writing I will reach for YAML every time. It really is amazing for that use case.

I find yaml tolerable for cases where ini would have been just as good. Anything else, and… no, it’s bad.

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

#184

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.

>JSON cannot be used for the kinds of tasks to which TEI is put. It's not even an option.

```js import * as fastXmlParser from 'fast-xml-parser'; const xmlParser = new fastXmlParser.XMLParser({ ignoreAttributes: false }); ```

Validate input as required with jschema.

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

#185
post #112

Earlier quoted context omitted.

"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…

Would it be possible to transform a large XML document into something on-disk that could be queried like a database by the XPath evaluator?

You'd basically be building an index into each node.

There's some fast databases that store prefix trees, which might be suitable for such a task actually (something like infinitydb). But building this database will basically take a while (it will require parsing the entire document). But i suppose if reading/querying is going to happen many times, its worth it?

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

#187

Earlier quoted context omitted.

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.

What actually prevents JSON from being used in these spaces? It seems to me that any XML structure can be represented in JSON. Personally, I've yet to come across an XML document I didn't wish was JSON, but perhaps in spaces I haven't worked with, it exists.

Have you ever written Markdown? Markdown is typically mostly human-readable text, interspersed with occasional formatting instructions. That's what XML is good for, except that it's more verbose but also considerably more flexible, more precise, and more powerful. Sure, you can losslessly translate any structural format into almost any other structural format, but that doesn't mean that working with the latter format will be as convenient or as efficient as working with the former.

XML can really shine in the markup role. It got such a bad rap because people used it as a pure data format, something it isn't very suited for.

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

#188
post #112

Earlier quoted context omitted.

"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…

Would it be possible to transform a large XML document into something on-disk that could be queried like a database by the XPath evaluator?

Like MarkLogic?

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

#189

Earlier quoted context omitted.

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 sale…

My favorite and only use of XSLT that still works pretty well is to allow people to browse my RSS feed as if it were a web page. https://joeldueck.com/feed.atom

>as if it were a web page.

Why the "as if"? Isn't it a web page by definition?

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

#190

> XML is now niche technology, but it's a bigger niche than you might think, and it's not going to go away any time soon. When you consider that .docx, .pptx, and .xlsx files are zipped XML archives, "niche" seems a misnomer.

especially .xlsx which is some "hold my beer" for someone trying to encode a dataframe in .xml :-(

Openpyxl is a great library.
Post reply on HN