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

131–140 of 245 posts

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

#131

Post by [deleted] »

eyelidlessness wrote: post #115
montroser wrote: post #3

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

I can’t say this with certainty, but I have some reason to suspect I might be partially to blame for this fun fact! A couple years ago, I stumbled on a discussion considering deprecation/removal of XSLT support in Chrome. At some point in the discussion, they mentioned observing a notable uptick in usage—enough of an uptick (from a baseline of approximately zero) that they backed out. The timing was closely correlate…

[deleted]

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

#132

Post by int_19h »

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.

XSL:FO is dead for all practical purposes.

XSLT was not popular for its original intended application - which is to say, serving XML data from web servers and translating it to HTML (or XSL:FO, or ...) on the client as needed. However, it was used plenty for XML processing outside of that particular niche.

New projects these days rarely have to process complicated XML to begin with. But when you do, I'd say XSLT (or perhaps better yet, XQuery) is a very useful tool to have in your toolbox.

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

#133

Post by int_19h »

tannhaeuser wrote: post #51
falcor84 wrote: post #12

Earlier quoted context omitted.

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

> XSLT 2 and 3 is a W3C standard written by the sole commercial provider of an XSLT 2 or 3 processor,

I was following the W3C XSLT mailing list for quite some time back when they were doing 3.x, and this does not strike me as accurate.

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

#134

Post by int_19h »

jerf wrote: post #29
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?

XPath is a very nice language for querying over XML. Most places pitch it as a "declarative" syntax, but as I am quite skeptical of "declarative" as a concept, you can also look at the vast majority of the XPath standard as a way to imperatively drive a multicursor over an XML document, diving in out and out nodes and extracting bits of text and such, without having to write the equivalent code in your language to do…

XQuery is the best of both worlds - you get almost all the benefits of XSLT like e.g. the ability to define your own functions, but with non-XML-based syntax that is a superset of XPath.

Basically the only thing it's missing in XQuery vs XSLT is template rules and their application; but IMO simple ones are just as easy to write explicitly, and complex rulesets are hard to reason about and maintain anyway.

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

#135

Post by int_19h »

Mountain_Skies wrote: post #90
da_chicken wrote: post #57

Earlier quoted context omitted.

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.

Attributes are way shorter to write.

That said, these days most Microsoft XML dialects are actually XAML-based, and in XAML attributes are basically syntactic sugar - you can write:
or

  
    123
(the dot in the syntax makes it possible for the XAML parser to distinguish nested elements that represent properties from nested elements that represent child objects)

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

#136

Post by int_19h »

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…

Curiously, one of the driving forces behind renewed interest in XML is that language models seem to handle large XML documents better than JSON. I suspect this has something to do with it being more redundant - e.g. closing tags including the element name - making it easier for the model to keep track of structure.

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

#137

Post by tracnar »

Nice! I tried using XQuery (superset of XPath 3) for a while through the BaseX implementation. It's pretty nice, but you have to face XML problems like namespaces, document order, attributes vs nodes, you don't know if you can have 0, 1 or more nodes, etc. Something I wish was more readily available would be to run XPath against JSON, yaml, etc. It's a nicer language than say jq, but its ties to XML sometimes make it hard to transfer.

Another pain point with XML is the lack of inline schema, so the languages around like XPath have to work with arbitrary structures unlike say JSON where you at least have basic primitives like map/dict, numbers, bool, etc

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

#138

Post by bbkane »

never_inline wrote: post #48
mickeyp wrote: post #14

Earlier quoted context omitted.

XPath is a superb query language for XML (or anything that you can structure as a DOM) --- it is also, with some obscure exceptions, the only query language with serious adoption, so it's an easy choice and readily available in XML tools. The only caveat is there are various spec versions and most never added support for newer versions. Let's look at JSON by comparison. Hmm, let's see: JSONPath, JMESPath, jq, jsonql,…

JQ is the most feature-rich of the bunch. It's defacto standard and I usually just default to it because it offers so much - assignment, various builtins such as base64 encoding. The disadvantage is that it's not easily embeddable in your own programs - so programs use JSONPath / Go templates often.

I also don't think there's a specification written for the jq query language, unlike https://jmespath.org/ , which as you mentioned also has more client libraries.

I too am probably going to embed jmespath in my app.I need it to allow users to fill CLI flags from config files, and it'll replace my crappy homegrown version ( https://github.com/bbkane/warg/blob/740663eeeb5e87c9225fb627... )

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

#140

Post by ajxs »

velcrovan wrote: post #69
tannhaeuser wrote: post #51

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

That's an awesome idea! Very cool! I might just do that for my own RSS feed, and credit you for the great idea.
Post reply on HN