13 ms·
Xee: A Modern XPath and XSLT Engine in Rust
- athanagor2 2y agoThe fact it could be compiled in WASM is a good thing, given the Chrome team was considering removing libxml and XSLT support a few years back. The reasons cited were mostly about security (and share of users). It's another proof that working on fundamental tools is a good thing.
- therealmarv 2y agonot WASM but there is also https://www.npmjs.com/package/saxon-js https://www.npmjs.com/package/saxon-js
- sntran 2y agoThis is pretty slow compared to libxslt.
- montroser 2y agoFun fact: XSLT still enjoys broad support across all major browsers: https://caniuse.com/?search=xslt https://caniuse.com/?search=xslt
- Telemakhos 2y agoThis is true only of XSLT 1.0. The current standard is 3.0.
- falcor84 2y agoOh, 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?
- Telemakhos 2y agoI think it's up to browser implementations, but JSON and JavaScript stole much of XML's thunder in the browser anyway, plus HTML5's relaxed tags won out over XHTML 4's strictness (strictness was a benefit if you were actually working with the data). There are still plenty of web-available uses of XML, like RSS and RDF and podcasts/OPML, but people are more likely to call xmlhttp.responseXML and parse a new DOM than wrap their head around XSL templates. The big place I've successfully used XSLT was in TEI, which nobody outside digital humanities uses. Even then, the XSLT processing is usually minimal, and Javascript is going to do a lot of work that XSL could have done.
- tannhaeuser 2y agoThere'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 sales, but also because it undermines W3C's own policy of at least two interworking implementations for a spec to get "recommendation" status. XSLT is of course a competent language for manipulating XML. It would be a good fit if your processing requires lots of XML literals/fragments to be copied into your target document since XSLT is an XML language itself. Though OTOH it uses XPath embedded in strings excessively, thereby distrusting XML syntax for a core part of its language itself, and coding XPath in XML attributes can be awkward due to restrictive contextual encoding rules for special characters and such. XSLT can be a maintenance burden if used casually/rarely, since revisiting XSLT requires substantial relearning and time investment due to its somewhat idiosyncratic nature. IDE support for discovery, refactoring, and test automation etc. is lacking.
- velcrovan 2y agoMy 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 https://joeldueck.com/feed.atom
- eyelidlessness 2y agoI 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 correlated with work I’d done to adapt a library, which originally used XSLT via native Node extensions, to browser XSLT APIs. The project isn’t especially “popular” in the colloquial sense of the term, but it does have a substantial niche user base. I’m not sure how much uptake the browser adaptation of this library has had since, but some quick napkin math suggested it was at least plausible that the uptick in usage they saw might have been the onslaught of automated testing I used to validate the change while I was working on it.
- deleted 2y ago[deleted]
- vanderZwan 2y agoAnd this kids is one more reason for us to use testing while developing
- ajxs 2y agoBeing 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?
- mvc 2y agoNice work. Xpath is a beast. Obvious why paligo would be interested too. Must be a lot of commercial documentation out there where the best representation they can get looks a bit XMLish.
- therealmarv 2y agoGreat 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 much more fun and easier to use in 2.0+ versions. For that reason I've never touched XSLT 3.0 (because I stuck to Saxon B 9.1 from 2009). I have no doubt it's a great spec but there should be other ways than only Saxon HE to run it in an open source way. It's like we have an amazing modern spec but only one browser engine to run it ;)
- Finnucane 2y agoI'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.
- sramsay 2y agoI 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.
- miki123211 2y agoXML 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.
- stuaxo 2y agoeXcellent, it's good to see new work on XSLT, reviled bysome it's actually great tech and useful in all sorts of places.
- airstrike 2y agoWhat problems are {elegantly, neatly, best} solved by using XPath and XSLT today that would make them reasonable choices over alternatives?
- mickeyp 2y agoXPath 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, ...
- trallnag 2y agoRecently discovered Jsonata thanks to AWS adding it to Step Functions. Feel free to add it to your enumeration
- never_inline 2y agoJQ 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.
- bbkane 2y agoI also don't think there's a specification written for the jq query language, unlike https://jmespath.org/ 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/740663eeeb5e87c9225fb62718c91c51a116ba13/config/jsonreader/jsonreader.go https://github.com/bbkane/warg/blob/740663eeeb5e87c9225fb627... )
- 2y ago
- mickeyp 2y agoIt'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 of missteps in the heyday of XML, I feel it has always been unfairly maligned. Look at all the people who reinvent XML tooling but for JSON, but not nearly as well. Luckily, people who value XML can still use it, provided the fit is right. But it's nice to see the tides turning. Most fashions really are cyclical.
- mickeyp 2y agoOh, and just to pile on to my own post: If you like React's JSX; enjoy its strictures and clean, readable "HTML"; then good news, you're writing XML (but without namespacing).
- Lammy 2y agoSee also: ECMAScript for XML (E4X) https://ecma-international.org/wp-content/uploads/ECMA-357_2nd_edition_december_2005.pdf https://ecma-international.org/wp-content/uploads/ECMA-357_2...
- Mountain_Skies 2y agoI made extensive use of XPath and XSL(T) back in their heyday and in general was fine with them but the architect astronauts who love showing off how clever they are with artificial complexity had a tendency to make use of XML tech to complicate things unnecessarily. Think that might be where many people's dislike of it came from, especially those whose first exposure wasn't learning through simple structures when XML was new but were thrown into the type of morass that develops when a tech is climbing the maturity curve.
- linguae 2y agoIt’s the “slope of enlightenment” phase of the Gartner hype cycle, where people are able to make sober assessments of technologies without undue influence from hype or its backlash. We’re long past the days where XML is used for everything, even when it’s inappropriate, and we’re also past the “trough of disillusionment” phase where people sought alternatives to XML. I think XML is good for expressing document formats and for configuration settings. I prefer JSON for data serialization, though.
- egh 2y agoVery cool! I recently wrote an XSLT 2 transpiler for js (https://github.com/egh/xjslt https://github.com/egh/xjslt) - it's nice to see some options out there! Writing the xpath engine is probably the hard part (I relied on fontoxpath). I'm going to be looking into what you have done for inspiration!
- vessenes 2y agoThis, 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. Happily to my mind the economics of easier-for-creators -> make web browsers and rendering engines either just DEAL with weird HTML, or else force people to use terse data specs like JSON won out. And we have a better and more interesting internet because of it. However, I’m old enough now to appreciate there is a place for very long-standing standards in the data and data transformation space, and if the XML folks want to pick up that banner, I’m for it. I guess another way to say it is that XML has always seemed to be a data standard which is intended to be what computers prefer, not people. I’m old enough to welcome both, finally.
- tzcnt 2y agoDeveloper 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 brackets any day.
- formerly_proven 2y agoWorking with large YAML documents is incredibly annoying and shows the benefit of closing tags.
- hkgjjgjfjfjfjf 2y ago[dead]
- rambojohnson 2y ago[flagged]
- geodel 2y agoMaybe similar reason as people deploy 100 requests a week micro service on multiple kubernetes clusters across 3 AZs to make sure it is highly available.
- rambojohnson 2y agoor like watching someone lovingly restore a fax machine with carbon fiber casing and a neural net to optimize transmission speed. I’m torn between admiration and existential despair.
- deleted 2y ago[deleted]
- samsk 2y agoNice ! I've a scrapper using XPath/XSLT extensively and 90% of the XPath selectors work like for years without a change. With CSS selectors I've had more problems...
- ebruchez 2y agoCSS selectors have spent the last few decades reinventing XPath. XPath introduced right from the beginning the notion of axes, which allow you to navigate down, up, preceding, following, etc. as makes sense. XPath also always had predicates, even in version 1.0. CSS just recently started supporting :has() and :is(), in particular. Eventually, CSS selectors will match XPath's query abilities, although with worse syntax.
- bambax 2y ago> CSS selectors have spent the last few decades reinventing XPath YES! This is so true! And ridiculous! It's a mystery why we didn't simply reuse XPath for selectors... it's all in there!!
- masklinn 2y ago> It's a mystery why we didn't simply reuse XPath for selectors... it's all in there!! It's not really a mystery: > CSS was first proposed by Håkon Wium Lie on 10 October 1994. [...] discussions on public mailing lists and inside World Wide Web Consortium resulted in the first W3C CSS Recommendation (CSS1) being released in 1996 > XPath 1.0 was published in 1999 CSS2 was released before XPath 1.0.
- ebruchez 2y agoFair enough. By the way, the original CSS from 1996 featured only: - the "descendant" combinator (whitespace) - the "class" selector (".foo") The 1998 CSS2 introduced "child", "following sibling", and attribute selectors. This state of things then remained unchanged forever (I see that Selectors Level 3 became a recommendation only in 2018?). On the other hand, in 1999, XPath already specified all those basic ways to navigate the DOM, and CSS still doesn't have them all as of 2025.
- trympet 2y agoI recently had the pleasure of using XSLT after never having seen it before. I used it to transform a huge 130K line XML manifest with MAPI property metadata into C# source code. It was so simple, readable, and intuitive to use.
- squiggleblaz 2y agoI learnt XSLT in university back in the early/mid part of the first decade of this century. I didn't much enjoy it. I've never used it, but all my career I've had to deal with terrible ad hoc templating languages. I recently had total freedom to choose what terrible ad hoc templating language to use, and I chose XSLT. I actually totally liked it: and it seemed to have everything I've needed. In previous jobs, there was always tickets that amounted to "make a fork of the terrible ad hoc templating language and hack it until it does this", but I reckon XSLT could do everything and then some.
- mattrighetti 2y agoI will definitely try this out! I have a service that extracts <meta> tags in webpages and to do that I'm currently using (and need) three different dependencies: html5ever, markup5ever_rcdom, markup5ever. I don't like those to be honest, the documentation is quite bad and it was difficult to understand how I should have used the libraries to achieve such a simple task. XPath on the other hand makes this extremely easy in comparison, I wonder how this will perform compared to my current solution.
- faassen 2y agoThanks! Unfortunately at this point there's no HTML parser frontend for Xee (and its underlying library Xot) yet (HTML 5 parser serialization is supported at least in code). It shouldn't be too hard to add at least HTML 5 support using something like html5ever.
- infogulch 2y agoThere 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/ideas.md https://github.com/Paligo/xee/blob/main/ideas.md How hard is it to implement XML/XSLT/XPATH streaming?
- wongarsu 2y ago100GB doesn't sound that out of reach. It's expensive in a laptop, but in a desktop that's about $300 of RAM and our supported by many consumer mainboards. Hetzner will rent me a dedicated server with that amount of ram for $61/month. If the payloads in question are in that range, the time spent to support streaming doesn't feel justified compared to just using a machine with more memory. Maybe reducing the size of the parsed representation would be worth it though, since that benefits nearly every use case
- infogulch 2y agoI just pulled the 100GB number out of nowhere, I have no idea how much overhead parsed xml consumes, it could be less or it could be more than 2.5x (it probably depends on the specific document in question). In any case I don't have $1500 to blow on a new computer with 100GB of ram in the unsubstantiated hope that it happens to fit, just so I can play with the Wikipedia data dump. And I don't think that's a reasonable floor for every person that wants to mess with big xml files.
- hyhjtgh 2y agoXml and textual formats in general are ill suited to such large documents. Step 1 should really be to convert and/or split the file into smaller parts.
- intrasight 2y ago
- jchw 2y agoI wonder if this could perhaps some day be used in Wine, for the MSXML implementations. Maybe not, since those implementations need to be bug-compatible where applications depend on said bugs; but the current implementation(s) are also not fantastic. I believe it is still using libxml2. (Aside: A long time ago, I had written an alternate XPath 1.1 implementation for Wine during GSoC, but rather shamefully, I never actually got it merged. Life became very hectic for me during that time period and I never really looped back to it. Still feel pretty bad about it all these years later.)
- infogulch 2y ago> I was at XML Prague, an XML conference There's an XML conference?!
- bartschuller 2y agoThere are at least 5: https://www.xmlprague.cz/ https://www.xmlprague.cz/ https://www.balisage.net/ https://www.balisage.net/ https://declarative.amsterdam/ https://declarative.amsterdam/ https://markupuk.org/ https://markupuk.org/ https://xmlsummerschool.org/ https://xmlsummerschool.org/
- MrVandemar 2y agoThere's some interesting papers in the balisage archives.
- dev_l1x_be 2y agoXML is the what OOP is for programming languages. Often overcomplicated, hard to follow, full of footguns.
- notfed 2y agoDoes it preserve whitespace? Something that I always found asinine about XSLT is that it wipes out whitespace when transforming. Imagine you have thousands of corporate XML files in source control, and you want to tranform them all, performing some simple mutation. XSLT claims to be fit for this job, but in practice your diff is going to be full of unintentional whitespace mangling.
- ebruchez 2y agoXSLT will perform the transformations that you instruct it to do. It does not wipe out whitespace just on its own. Do you mean that you'd like facilities to nicely reindent the output?
- notfed 2y ago> It does not wipe out whitespace just on its own. Sounds nice but doesn't match my lived experience with both Chrome's built-in XSLT processor and `xsltproc`. (I was using XSLT 1.0, for legacy reasons, so maybe this is an XSLT 1.0 issue?) > Do you mean that you'd like facilities to nicely reindent the output? No, I do mean preserve whitespace (i.e., formatting), such as between elements and between attributes.
- froh 2y agousually whitespace (in) significance is specified in the XML schema. so if you provide a schema and instruct the xslt engine to comply with the schema, do your issues persist?
- 1shooner 2y agoI miss the declarative purity of XSLT as an HTML templating layer. I'd love to know if there is a similar system for more popular/current web stack.
- yxhuvud 2y agoI hope this will be packaged into shared libraries at some point so that languages that isn't rust will get access to it.
- faitswulff 2y agoThe author mentions Python bindings in the post.
- threecheese 2y agoThis is great, I’ve been looking for performant and safe XML processing to replace IBM stuff (websphere/datapower) that we really only keep around for hw accelerated payload processing. At our scale, lxml and others + BYO gateway tech has a similar run cost even considering IBM licensing. I hate running their crap, which requires k8s at a version that’s some hair-thin slice above the minimum supported EKS version, it’s almost like they want us to live in 24/7 fear of being OOS.
- ianand 2y agoFun fact: A decade ago the designer of HAML and Sass created a modern alternative to XSLT. https://en.wikipedia.org/wiki/Tritium_(programming_language) https://en.wikipedia.org/wiki/Tritium_(programming_language)
- smitty1e 2y ago> 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.
- blacklion 2y agoDoes 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.
- kondro 2y agoThere 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.
- blacklion 2y agoI see a lot of XML APIs and formats around me, it is true. But it is machine-machine formats or complex configuration files formats which doesn't need visualization. It needs schema support and tooling, but not visualization or transformation. It is more serialization formats for complex object trees, and all processing is done on these object trees, not XML itself. But of course, I see only a part of the picture.
- int_19h 2y agoXSL: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.
- mdaniel 2y ago> XSL:FO is dead for all practical purposes. As opposed to what for cooking "PDF via XML" files? Because I can assure you than feeding rando.odt into $(libreoffice -pdf $TMPDIR/ohgawd) is 100% not the same as $(fop -fo $TMPDIR/my.fo -pdf $TMPDIR/out.pdf)
- riedel 2y agoLove 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/ 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.
- tracnar 2y agoNice! 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
- shadowtree 2y agoThrowback shoutout to Steve Muench and his genius method of grouping elements in XSLT 1.0. So good it has its own Wikipedia page! https://en.wikipedia.org/wiki/XSLT/Muenchian_grouping https://en.wikipedia.org/wiki/XSLT/Muenchian_grouping I mean, talk about hacker cred.
- immibis 2y agoXSLT is great for nerd cred, when someone selects "view source" on your page and there's not an HTML tag in sight. I did this once. Maybe it's good for compression, but probably not by a factor much bigger than gzip/brotli/zstd.
- o_pax 2y agoThis is really good news, I am looking forward to trying it out! Is XQuery also planned as an additional frontend? By the way, there is also χrust, a rust project working towards pretty similar goals (XPath 3.1, XQuery 3.1 and XSLT 3.0). At first glance, the architecture also seems quite similar, it is not as far along, though. Have you had any contact with them?
- mdaniel 2y agoI always hate it when license files have "yes, but" language in them because if the license file differs in some non-obvious way, now I have to pay lawyers to interpret it https://github.com/Paligo/xee/blob/xee-v0.1.5/COPYRIGHT https://github.com/Paligo/xee/blob/xee-v0.1.5/COPYRIGHT And that goes double for when there is a separate LICENSE file in the repo https://github.com/Paligo/xee/blob/xee-v0.1.5/LICENSE-MIT https://github.com/Paligo/xee/blob/xee-v0.1.5/LICENSE-MIT
- hpfr 2y agoDoesn’t look like “yes, but” language to me. Looks like the code is plain old MIT and the author is doing their due diligence with respect to vendored content in the repository subject to different licensing. Seems like they are being paid by a company to work on this, so it’s not surprising that they actually pay attention to copyright. The fact that many project maintainers forget about vendored content and haphazardly slap the MIT license (or whatever) verbatim into a LICENSE file doesn’t actually give you a get-out-of-paying-lawyers-free card! If anything, Xee’s COPYRIGHT file gives me more confidence in my legal footing than an unadulterated LICENSE file would. It indicates the maintainer at least has a basic understanding of how copyright applies to their project.
- nashashmi 2y agoJust want to say that Microsoft has some sort of implementation of an xml application using Microsoft word or Ms word. But I have struggled to find examples I can use, but for a long time I have been trying to convert an office repository of corporate resumes to xml.
- xvilka 2y agoI miss XHTML and XSL times. Time, when Web would have been more prepared for the AI consumption, less dynamic nonsense, and more focus on the actual content. Time shows all these Flash and Java gimmicks died off.
- deleted 2y ago[deleted]
- torginus 2y agoI yearn for the day when people will stop considering the main advertising bullet point feature that their software was written in Rust. Rust 1.0 was released a decade ago, plenty of time for its alleged technical advantages to become apparent. It's like a handbag whose main claim to being a premium product isn't workmanship or materials, but that it has Gucci on its side.
- resonious 2y agoPersonally I consider the programming language used for a piece of software to be similar to the materials used for a handbag.
- chuckadams 2y ago> It's like a handbag whose main claim to being a premium product isn't workmanship or materials, but that it has Gucci on its side. Knockoffs aside, the latter is intended to serve as a proxy for the former. I too will be happy when Rust is the boring everyday choice, but in 2025 we still see new buffer overflows every day. And if I'm picking a library, I still want to know if it's in the same language as the app it's going into.
- forty 2y agoAn xpath/xslt engine is something you might want to include in other software, the programming language used might be an important information for this purpose.
- hcayless 2y agoThis sounds fantastic! Thank you for your work. Now I gotta go learn Rust :-).
- chromatin 2y agoNCBI still emits XML from their most prominent databases (e.g., PubMed). I'm looking forward to adopting this library into some of my production code that interfaces with PubMed!
- nickm12 2y agoThis 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.