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

171–180 of 245 posts

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

#171

Post by bigstrat2003 »

jlarocco wrote: post #100
weinzierl wrote: post #68

Earlier quoted context omitted.

"This, thirty years later, is the best pitch for XML I’ve read." I wish someone would write "XML - The Good Parts" . Others might argue that this is JSON but I'd disagree: - No comments is a non-starter - No proper integers - No date format - Schema validation is a primitive toy compared what we had for XML - Lack of allowed trailing commas YAML ain't better. I hated whitespace handling in XML, it's a miracle how YAM…

It's funny to hear people in the comments here talk about XML in the past tense. I know it's passé in the web dev world, but in my work we still work with XML all the time. We even have work in our queue to add support for new data sources built on XML (specifically QIF https://qifstandards.org/ ). It's fine with me... I've come to like XML. It's nice to have a standard, easy way to do seschemas, validators, processo…

> I know it's passé in the web dev world...

That is because the web dev world is unfortunately obsessed with the current thing. They chase trends like their lives depend on it.

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

#172

Post by hpfr »

mdaniel wrote: post #166

I 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 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

Doesn’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.

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

#173

Post by bigstrat2003 »

baq wrote: post #62
vessenes wrote: post #13

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…

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.

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

#174

Post by [deleted] »

chuckadams wrote: post #40
tzcnt wrote: 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…

You haven’t felt hate until you’ve counted spaces in your Helm templates in order to know what value to put after `nindent`. The punchline is that k8s doesn’t even speak yaml, the protocol is all json and it’s the tooling that inflicts yaml on us. I can live with yaml as a config format, but once logic starts creeping in, give me anything else.

[deleted]

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

#175

Post by nashashmi »

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

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

#176

Post by notfed »

ebruchez wrote: post #78
notfed wrote: post #75

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

XSLT 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?

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

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

#177

Post by winstonewert »

sramsay wrote: post #102
Finnucane wrote: post #74

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.

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.

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

#178

Post by lmz »

immibis wrote: post #143
caspper69 wrote: post #110

Earlier quoted context omitted.

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.

Java tried to, and mostly successfully did, run trusted and untrusted code in the same VM. Your applet code ran in the same VM as all the code for managing applets. However, holes were frequent enough that they abandoned the whole idea. (Instead of sandboxing the VM as a whole? Why?)

The whole applet thing was already slow enough then without scrutinizing every syscall it makes.

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

#179

Post by kfuse »

amy_petrik wrote: post #169
miki123211 wrote: post #130

Earlier quoted context omitted.

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

XML is honestly the greatest and I'm not sure why it didn't take off. People sometimes ask me, "what impacted the humanity the most - electricity? antibiotics? combustion engines?" -- no, no, and no, it was XML. Everything can be expressed in XML, and basically everything can read and write XML. It's like the whole world could read and write the same files. Imagine what if those files included programs, that's what X…

Maybe one reason is its verbosity for small everyday tasks, like config files or when representing arrays. If xml allowed empty tags there probably would be no need for json.

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

#180

Post by int_19h »

mdaniel wrote: post #163
int_19h wrote: post #132

Earlier quoted context omitted.

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…

> 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)

As opposed to code in e.g. Java that uses the built-in XML APIs and some third party PDF output lib.
Post reply on HN