Live data from Hacker News

Xee: A Modern XPath and XSLT Engine in Rust

blog.startifact.com

101–110 of 245 posts

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

#101
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…

JSON5 is a real sweet spot for me. Closing brackets, but I don't have to type every tag twice. Comments and trailing commas.

I find for deeply hierarchical data that XML is much easier to read.

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

#102

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…

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.

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

#103
post #72

Earlier quoted context omitted.

You should try using a LISP like Racket for XML. Because XML can be expressed directly as S-expressions, XML and LISP go together like peanut butter and jelly. Hello world (greeting ((attr "val") (href "#")) "Hello " (thing "world"))

In my experience, at least with Clojure, it's much more convenient to serialize XML into a map-like structure. With your example, the data structure would look like so. {:tag :greeting :attrs {:href "#" :attr "val"} :content ["Hello" {:tag :thing :content ["world"]}]} Some people use namespaced keywords (e.g. :xml/tag) to help disambiguate keys in the map. This kind of data structure tends to be more convenient than…

I have not looked into the use of zippers for this purpose, but I will do so!

Racket has helper libraries like TxExpr (https://docs.racket-lang.org/txexpr/index.html) that make it pretty easy to manipulate S-expressions of this kind.

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

#104

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…

You should try using a LISP like Racket for XML. Because XML can be expressed directly as S-expressions, XML and LISP go together like peanut butter and jelly. Hello world (greeting ((attr "val") (href "#")) "Hello " (thing "world"))

This looks like it loses the distinction between attributes and nested tags?

As in, I don't see a difference between `(attr "val")` which expresses an attribute key/value pair and `(thing "world")` which expresses a tag/content relationship. Even if I thought the rule might be "if the first element of the list is a list itself then it should be interpreted as a set of attribute key value pairs" then I would still be ambiguous with:

    (foo (bar "baz") "content")
which could serialize to either:

    content
or:

    bazcontent
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.

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

#105

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…

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.

My hope is that we can get a little collective together that is willing to invest in this tooling, either with time or money. I didn't have much hope, but after seeing the positive response today more than before.

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

#106
post #19

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…

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…

> Developer ergonomics is drastically underappreciated, even in modern times.

When was the last time you had an editor that wouldn't just auto close the current tag with "</" ? I mean it's a god-send for knowing where you are at in large structure. You aren't scrolling to the top to find which tag you are in.

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

#107
post #79
post #50

Earlier quoted context omitted.

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…

> I want to get XSLT 3.0 working properly first May I ask why? I used to do a lot of XSLT in 2007-2012 and stuck with XSLT 2.0. I don't know what's in 3.0 as I've never actually tried it but I never felt there was some feature missing from 2.0 that prevented me to do something. As for streaming, an intermediary step would be the ability to cut up a big XML file in smaller ones. A big XML document is almost always the…

XSLT has been a goal of this project from the start, as my customer uses it. XSLT 3.0 simply as that's the latest specification. What tooling do you use for XSLT 2.0?

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

#108
post #88

Earlier quoted context omitted.

> Elements are for data. Attributes are evil This is like, your opinion, man... ;-) You can devise your schema any way you want. Attributes are great, and they exist in HTML in the form of datasets, which, as usual, are a poorly-specified and ill-designed rethinking of XML attributes > Documents without a schema should not make your tools panic or complain They don't. You absolutely don't need a schema. If you declar…

Sometime attribute use goes too far such as when they contain comma separated lists of items.

Sure, but that's not the fault of the format itself, is it? You can write extremely long enumerations in any natural language -- that's the author's fault.

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

#109
post #79

Earlier quoted context omitted.

> I want to get XSLT 3.0 working properly first May I ask why? I used to do a lot of XSLT in 2007-2012 and stuck with XSLT 2.0. I don't know what's in 3.0 as I've never actually tried it but I never felt there was some feature missing from 2.0 that prevented me to do something. As for streaming, an intermediary step would be the ability to cut up a big XML file in smaller ones. A big XML document is almost always the…

XSLT has been a goal of this project from the start, as my customer uses it. XSLT 3.0 simply as that's the latest specification. What tooling do you use for XSLT 2.0?

Saxon's free version, which IIRC only implemented 2.0.

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

#110

Earlier quoted context omitted.

> XML has always seemed to be a data standard which is intended to be what computers prefer, not people. On one hand, you aren't wrong: XML has in fact been used for machine-to-machine communication mostly. OTOH, XML was just introduced as a subset of SGML doing away with the need of vocabulary-specific markup declarations for mere parsing in favor of always requiring explicit start- and end-element tags. Whereas HTM…

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…

Had we had better process isolation in the mid-90s, I assume web application development would mostly be Java apps, with a mini-vm for each one (sort of a qubes like environment).

We just couldn't keeps apps' hands out of the cookie jar back then.

Post reply on HN