Xee - Rustで実装された最新のXPathおよびXSLTエンジン

 (blog.startifact.com)
11 ポイント 投稿者 GN⁺ 2025-03-30 | 1件のコメント | WhatsAppで共有
  • XeeはRustで開発されたXML実行エンジンで、最新バージョンのXPath 3.1とXSLT 3.0をサポートする
    • XPathはXMLクエリ言語であり、XSLTはXML文書を別の文書へ変換する言語
  • コマンドラインツールxeeとRustライブラリxee-xpathで構成されており、XPathクエリを実行できる
  • Rustの性能と統合のしやすさを土台に、さまざまな言語へ拡張可能（例: PHPバインディングあり）
  • 将来的にはWebAssembly(WASM)により、ブラウザでも実行可能になると期待される

XMLの歴史と現在の位置づけ

  • XMLは1990年代末に登場し、2000年代前半までは非常に人気の高い技術だった
  • その後JSONなどの登場で主流ではなくなったが、今でも多くのデータ保存や転送に使われており、文書形式（docbook、JATS）やWebの一部（SVG、MathML）などでも広く使われている
  • XMLは今なお重要な技術であり、XeeはXML技術のモダン化を目指している
  • 開発者はPython向けXMLライブラリlxmlを作った経験を持っており、RustとXMLの両方をよく理解する稀有な開発者として、Xeeを通じてXMLの世界に復帰することになった

XPathとXSLTは完全なプログラミング言語

  • XPathはXMLを探索・クエリする言語であり、関数型言語として変数、条件分岐、反復、関数定義などを含む
  • XSLTはテンプレートベースの変換言語で、XPathを組み込み式言語として使い、XMLを別の形式へ変換する
  • どちらの言語も強力な機能を備えた正式なプログラミング言語である

現在のXMLオープンソーススタックの限界

  • Javaエコシステムには、最新のXPath/XSLT実装としてSaxonが存在し、多様な言語バインディングとJavaScriptランタイムも提供されている
  • 一方で多くのLinuxディストリビューションなどでは、libxml2とlibxsltが標準で提供されている
  • これらのCライブラリはXPath 1.0とXSLT 1.0しかサポートしておらず、1999年に出た仕様にとどまっている
  • 最新仕様をサポートするオープンソースの代替が不足している状況で、XeeはRustで書かれたモダンな代替を提示する

XML世界の仕様中心文化

  • XMLコミュニティは仕様中心の文化が強い → 機能が仕様に無ければ「本物の」機能とは見なされない
  • そのおかげで開発速度は遅いが、土台は非常に堅牢
  • XPathとXQueryのRESTフレームワークであるRESTXQは2012年に議論され、2024年になっても仕様更新が議論中である

Xeeの言語実装アーキテクチャ

  • Crafting Interpretersの本を参考に実装されている
  • XPathはトークン化 → AST → 中間表現(IR) → バイトコード → インタプリタ実行という段階を経る
  • このバイトコードインタプリタは、PythonやJavaなどで使われるスタックマシンに似ている
  • XSLTも同じアーキテクチャを基盤として実装されており、フロントエンドだけが異なり、残りの構成要素はXPathと同一に使われる

膨大なXML/XPath/XSLT仕様の世界

  • XPath 3.1とXSLT 3.0は、1.0バージョンと比べてはるかに複雑になり、機能も増えている
  • 実装のために参照すべき仕様書だけで1800ページを超え、さまざまな仕様が相互依存している
  • 例えば:
    • XPath 3.1、XQuery/XPathデータモデル、関数と演算子、XML Schema（構造/データ型）
    • XSLT 3.0、シリアライズ仕様、XML名前空間、XML Base、xml:id など
    • 正規表現機能も含まれるため、別個のregexエンジンも実装 → regexml

Xeeの現在の実装状況

  • XPath 3.1のコア言語および標準ライブラリの大半の実装が完了
  • 標準ライブラリの一部のフォーマット関連関数はまだ未実装
  • XPath 3.1互換性テストでは21859件中20130件のテストに合格（約92%）
  • テストは約13秒以内にすべて実行される → 非常に高速な性能
  • XSLTはまだ完成していないが、基盤構造は整っており拡張可能

コントリビューター募集

  • RustとXMLに関心のある開発者、プログラミング言語実装やクエリ最適化に興味のある人を歓迎
  • 仕様ベースの機能実装、最適化作業、クエリ性能改善など、さまざまな領域で貢献可能
  • XeeはJavaエコシステム以外のモダンなXML実装として、オープンソースコミュニティの支援が必要な段階にある

私はまだイケている。たとえXMLを扱っていても。

関連記事

1件のコメント

 
GN⁺ 2025-03-30
Hacker Newsの意見

  • 誰かが真のオープンソースの XSLT 3 と XPath 3 の実装を作ったのを見てうれしい

    • 過去のプロジェクトでは XSLT & XPath 1.0 しか使っていなかった。Java/.NET の世界以外ではサポートが不足していたため
    • Saxon は素晴らしかったが、オープンソース界隈でもっと多くの XSLT 2.0 および XPath 2.0 以上の実装があればよいのにと思う
    • XSLT 3.0 は優れた仕様だが、オープンソース方式で動かせる別の手段が必要

  • XML ソースは大量に存在する

    • 例えば、Wikipedia のアーカイブは非圧縮テキストで 42GB ある
    • これを完全にパース済みの形でメモリに保持すると、100GB 以上必要になる可能性がある
    • ストリーミングが解決策だが、まだサポートされていない

  • XML を使うのは今でもクールだ

    • Rust で書かれた高性能・高品質のライブラリが必要
    • それを基盤にした Python ライブラリは良い土台になりそう

  • XML はデータ相互運用性のための標準ベースのアプローチだ

    • 初めて学んだときは開発者フレンドリーではなくて嫌だった
    • しかし今では、長年使われてきた標準の価値を理解できるようになった
    • XML はコンピュータが好むデータ標準のように見える

  • XSLT は主要ブラウザで今でも広くサポートされている

  • WASM にコンパイルできる点は前向きだ

    • Chrome チームが libxml と XSLT のサポートを削除しようとしたことがあった
    • 基盤ツールへの取り組みが重要であることを示す証拠だ

  • 最近 XSLT 2 トランスパイラを書いた

    • XPath エンジンを書くのが最も難しい部分だった

  • XPath と XSLT が今日どのような問題をエレガントに解決しているのか気になる

  • Java 以外の領域で作業するのが好きだ

    • XML リーダーにエラー修正機能があることは重要

  • この実装がいつか Wine で MSXML 実装に使われるようになるのか気になる

    • 以前 Wine 向けに XPath 1.1 実装を書いたが、マージできなかった