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

91–100 of 245 posts

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

#91

Post by IgorPartola »

tannhaeuser wrote: post #28
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 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 even external peripherals.

If there was ever scope creep in a project this would be it. And given the recent discussion on here of curses based interfaces it reminded me just how primitive other GUI application layout tools can be while still achieving amazing results. Even something like GTK does not need the intense level of layout engine support and yet is somehow considered richer in some ways and probably more performant for a lot of stuff that’s done with it.

So I am curious what web application development would look like today if it wasn’t for HTML being “good enough”.

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

#92

Post by magicalhippo »

01HNNWZ0MV43FF wrote: post #36
infogulch wrote: post #26

There 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/ide…

Is that all in one big document?

We regularly parse ~1GB XML documents at work, and got laughed at by someone I know who worked with bulk invoices when I called it a large XML file.

Not sure how common 100GB files are but I can certainly image that being the norm in certain niches.

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

#93

Post by giantrobot »

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

To this day I'm frustrated that developers (web devs mostly) tossed XML aside for JSON and the requisite JavaScript to replace relatively straight forward things like converting structured data to something a browser could display.

I bought into and still believe in the separation of data and its presentation. This a place where XML/XSLT was very awesome despite some poor ergonomics.

An RSS XML document could live at an endpoint and contain in-line comments, extra data in separate namespaces, and generally be really useful structured data for any user agent or tool to ingest. An RSS reader or web spider could process the data directly, an XSLT stylesheet could let a web browser display a nice HTML/CSS output, and any other tools could use the data as well. Even better any user agent ingesting the XML could use in-built tools to validate the document.

XSLT to convert an XML feed to pretty HTML is a great example of the utility. Browsers have fast built-in conversion engines and the resulting HTML produced has all the normal capabilities of HTML including CSS and JavaScript. To the uninitiated: the XML feed just links to an external XSL stylesheet, when a web browser fetches the XML it grabs the stylesheet and transforms the XML to an HTML (or XHTML) representation that's then fed back into the browser.

A feed reader will fetch the XML and process it directly as RSS data and ignore the stylesheet. Some other user agent could fetch the XML and ignore its linked stylesheet but provide its own to process the RSS data. Since the feed has a declared schema pretty much any stylesheet written to understand that schema will work. For instance you could turn an RSS feed into a PDF with XSLT.

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

#94

Post by threecheese »

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

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

#95

Post by wiremine »

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…

> developer ergonomics

That was a huge reason JSON took over.

Another reason was the overall XML ecosystem grew unwieldy and difficult to navigate: XPath, XSLT, SOAP, WSDL, Xpointer, XLink, SOAP, XForms... They all made sense in their own way, but it was difficult to master them all. That complexity, plus the poor ergonomics, is what paved the way for JSON to become preferred.

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

#96

Post by [deleted] »

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…

[deleted]

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

#97

Post by da_chicken »

bambax wrote: post #88
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…

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

No, the problem with attributes is that people consistently misuse them. So many things about XML break down when you make everything a self closing tag with 50 attributes. So many programmers just seem to say, "oh, it's shorter text so it must be inherently better" or "oh it's one-to-one so I should strictly avoid anything resembling a heirarchy."

Like I think this guy is mostly correct in identifying bad XML: https://www.devever.net/~hl/xml

Though I don't necessarily agree with the "data format" framing. This idea that markup languages are not data formats seems confused.

> They don't. You absolutely don't need a schema. If you declare a schema, it should exist. If not, no problem?

I agree that they should not.

However, I have used many tools that puke when presented with XML fragments or XML with no schema.

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

#98

Post by Mountain_Skies »

bambax wrote: post #88
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…

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

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

#100

Post by jlarocco »

weinzierl wrote: post #68
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…

"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, processors, queries, etc. It can be overdone and it's not for every use case, but it's pretty good at what it does.

Post reply on HN