▲

Xee - Rust로 구현된 최신 XPath 및 XSLT 엔진

 (blog.startifact.com)
10P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 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)이나 웹의 일부(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 런타임도 제공됨
  • 반면 대부분의 리눅스 배포판 등에서는 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을 다루지만.

▲
GN⁺ 3일전  [-]
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 구현을 작성했지만, 병합하지 못했음
답변달기