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

231–240 of 245 posts

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

#231

Post by amy_petrik »

geocar wrote: post #192
winstonewert wrote: post #177

Earlier quoted context omitted.

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.

> It seems to me that any XML structure can be represented in JSON Well it can't: JSON has no processing instructions, no references, no comments, JSON "numbers" are problematic, and JSON arrays can't have attributes, so you're stuck with some kind of additional protocol that maps the two. For something that is basically text (like an HTML document) or a list of dictionaries (like RSS) it may not seem obvious what th…

> and then you use them as &#x; maybe you are familiar with < representing Okay. This is syntactically painful, APL or J tier. C++ just uses "&" to indicate a reference. That's a lot of people's issue with XML, you get the syntactic pain of APL with the verbosity pain of Java.

> I have to implement special logic for that (this is built-in to XML). If they implement dates, sometimes it's unix-time, sometimes it's 1000x off from that, sometimes it's a ISO8601-inspired string, and fuck sometimes I just get an HTTP date. And so on.

Special logic is built into every real-world programming scenario ever. It just means the programmer had to diverge from ideal to make something work. Unpleasant but vanilla and common. I don't see how XML magically solved the date issue forever. For example, I could just toss in UNIXtime or 324234234 or 3234234234234. The argument seems to be "ah yes, but if everyone uses this XML date feature it's solved!" but not so. It's a special case of "if everyone did the same thing, it would be solved". But nobody does the same thing.

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

#232

Post by immibis »

zoogeny wrote: post #227
immibis wrote: post #144

Earlier quoted context omitted.

> In fact, this ambiguity between attributes and children has always been one of the head scratching things for me about XML. Well, the thing I've always disliked the most is namespaces but that is another matter. Just remember that it's a markup language, and then it's not head-scratching at all: the text is the text being marked up, and the attribute values are the attribute of the markup - things like colour and f…

When you say "those people", you mean people like me who (used to) have to navigate how to model structured data using XML. I think the attribute vs. child distinction makes sense in a very flat hierarchy where you are marking up text but quickly devolves into ambiguity for many other uses cases. I mean, if I'm modeling a node in some structured format, making a decision about "what is the attribute of the person nod…

When using XML for structured data the intended way, everything that is a string value (as opposed to a node hierarchy) would be an attribute. There's no text, so there would be no text.

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

#233

Post by nickm12 »

This is fantastic to see! I've used XML off and on since it was the red hot tech of the early 2000s. I wouldn't choose it today for a green field project, but it's still around in so many places, so we definitely need a high-performance, high-quality library written in Rust for this.

This could become a great foundation for a typed, (mostly) etree-compatible, python library built on top of this. I've used lxml for years and it's still my goto, but there are lots of places where it could be modernized.

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

#234

Post by BoingBoomTschak »

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.

And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. The query part isn't even that well done, compared to XPath/JSONPath.

I said goodbye to it a few weeks ago, personally (https://world-playground-deceit.net/blog/2025/03/a-common-li... https://world-playground-deceit.net/blog/2025/03/speeding-up...)

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

#235

Post by winstonewert »

ssdspoimdsjvv wrote: post #223
winstonewert wrote: post #211

Earlier quoted context omitted.

`{ type: "p", children: [{type: "text", text: "How would you represent "}, {type: "b", children: [{type: "i", children: [{type: "text", text: "mixed content"}]], {type: "text", text: " in JSON?"]}` or: `{paragraphs: [{spans: [{ text: "How you represent "}, {bold: true, italic: true, text: "mixed content"},{text: " in JSON?"}]}`

Oh sure, it can be represented. But now JSON is the one being noisy, ugly and verbose.

My specific claim was that you could represent it in JSON, so you can't claim, as the post I responded to did, that JSON "cannot be used."

I'll fully grant, I don't want to write a document by hand in either of the JSON formats I suggested. Although, given the choice, I'd rather receive it in that format to be parsed than in any XML format.

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

#236

Post by geocar »

amy_petrik wrote: post #231
geocar wrote: post #192

Earlier quoted context omitted.

> It seems to me that any XML structure can be represented in JSON Well it can't: JSON has no processing instructions, no references, no comments, JSON "numbers" are problematic, and JSON arrays can't have attributes, so you're stuck with some kind of additional protocol that maps the two. For something that is basically text (like an HTML document) or a list of dictionaries (like RSS) it may not seem obvious what th…

> and then you use them as &#x; maybe you are familiar with < representing Okay. This is syntactically painful, APL or J tier. C++ just uses "&" to indicate a reference. That's a lot of people's issue with XML, you get the syntactic pain of APL with the verbosity pain of Java. > I have to implement special logic for that (this is built-in to XML). If they implement dates, sometimes it's unix-time, sometimes it's 1…

I think you have a totally skewed idea about what is going on.

Most protocols are used by exactly two parties; I meet someone who wants to have their computer talk to mine and so we have to agree on a protocol for doing so.

When we agree to use XML, they use that exact date format because I just ask for it. If someone wanted me to produce some weird timestamp-format, I'd ask for whatever xslt they want to include in the payload.

When we agree to use JSON, schema says integers, email say "unix time", integration testing we discover it's "whatever Date.now() says" and a few months later I discover their computer doesn't know the difference between UTC and GMT.

Also: I like APL.

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

#237

Post by mdaniel »

BoingBoomTschak wrote: post #234
never_inline wrote: post #48

Earlier quoted context omitted.

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.

And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. The query part isn't even that well done, compared to XPath/JSONPath. I said goodbye to it a few weeks ago, personally ( https://world-playground-deceit.net/blog/2025/03/a-common-li... https://world-playground-deceit.net/blog/2025/03/speeding-up... )

> And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python.

Oh, yeah, I 100% want to type this 15 times a day

  # I'll grant you the imports, in the spirit of fairness
  aws ec2 describe-instances | python -c '
    for r in json.load(sys.stdin)["Reservations"]:
      print("\n".join(i["PrivateIpAddress"] for i in r["Instances"]))
  '
because that is undoubtedly better than

  aws ec2 describe-instances | jq -r '.Reservations[].Instances[].PrivateIpAddress'
I mean, seriously, who can read that terrible DSL with all of its line noise

> The query part isn't even that well done, compared to XPath/JSONPath.

XPath I'll grant you, because it's actually very strong but putting JSONPath near jq in a "could be improved" debate tells me you're just not serious. JSONPath is a straight up farce

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

#238

Post by riedel »

ssdspoimdsjvv wrote: post #194
riedel wrote: post #121

Earlier quoted context omitted.

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.

Streaming is defined in the XSLT 3 spec: https://www.w3.org/TR/xslt-30/#streamability . When you want to use streaming, you are confined to a subset of XPath that is "guaranteed streamable", e.g. you can't just freely navigate the tree anymore. There are some special instructions in XSLT such as and that make it easier to collect your results. Saxon's paid edition supports it. I've done it a few times, but you have t…

This was as I remember under development at the time. However, if working on bounded memory on communication buffers it, without remembering all the details, it was a pain not because of XSLT but mostly its interactions with XPATH. I was at the time formally looking into hedge grammars and visibly pushdown automata as formal basis, but to me it seemed at the time, that formal complexity was unnecessarily pushed beyond what was straightforward feasible. As I said it was about transforming binary (intermediate) representations of XML. Use case was actually to build message middlewares/routers for IoT stuff at the time. IMHO also the picked binary XML standards where mostly the wrong choice for small embedded systems (interestingly MPEG 7 is btw one of the few standards that supports rather nice streaming binary XML. I think however it is only used in digital broadcasting)

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

#239

Post by BoingBoomTschak »

mdaniel wrote: post #237
BoingBoomTschak wrote: post #234

Earlier quoted context omitted.

And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. The query part isn't even that well done, compared to XPath/JSONPath. I said goodbye to it a few weeks ago, personally ( https://world-playground-deceit.net/blog/2025/03/a-common-li... https://world-playground-deceit.net/blog/2025/03/speeding-up... )

> And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. Oh, yeah, I 100% want to type this 15 times a day # I'll grant you the imports, in the spirit of fairness aws ec2 describe-instances | python -c ' for r in json.load(sys.stdin)["Reservations"]: print("\n".join(i["PrivateIpAddress"] for i in r["Instances"])) ' because that is undoubtedly bet…

1) You realize the boilerplate of reading and serializing can be abstracted, right?

2) I didn't say "replace jq with Python", but that the language part (not the functions) of jq is horrible and didn't need to be invented. Same as Avisynth vs Vapoursynth.

3) I only mentioned Python as an example, I wouldn't choose a language that needs newlines in this specific case.

For example, in my own case, this expression is `cljq '(? $ "Reservations" * "Instances" * "PrivateIpAddress")` and if I need to do more complicated stuff (map, filter, group, etc...), I use CL instead of a bespoke, ad-hoc DSL that I never remember.

> JSONPath is a straight up farce

Why? At least it's specified (though you might say that jq is too, through jaq).

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

#240

Post by merb »

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.

Schematron / Peppol / electronic invoices inside the eu (since some stuff is based on as2 / as4 , stuff like saml but for sending invoices)
Post reply on HN