[xml] XSLT는 그만한 가치가 있습니까? [닫은]

Program / 글쓴이

얼마 전, 저자가 콘텐츠 (교육 과정 자료)를 간단한 형식으로 작성한 다음 XSLT를 통해 HTML로 변환 할 수 있도록 html-esque XML 스키마를 디자인하는 프로젝트를 시작했습니다. 나는 잠시 동안 그것을 가지고 놀았고 그것을 매우 기본적인 수준으로 얻었지만 내가 직면 한 한계 (내 지식의 한계 일 수 있음)와 도랑을 제안하는 블로그를 읽을 때 너무 짜증이났습니다. XSLT를 사용하고 원하는 언어로 자신의 XML-to-what-what 파서를 작성하면 열렬히 그것에 뛰어 들었고 훌륭하게 작동했습니다.

나는 지금까지도 작업을하고 있으며 ( 실제로는 SO 대신에 지금 작업해야합니다. ) XSLT를 버리는 결정이 다음과 같았다고 생각하게하는 점점 더 많은 것들을보고 있습니다. 좋은 것.

나는 XSLT가 인정 된 표준이라는 점에서 그 자리가 있다는 것을 알고 있으며 모든 사람이 자신의 통역사를 작성하면 그들 중 90 %가 TheDailyWTF에 올라갈 것이라는 점을 알고 있습니다. 하지만 대부분의 프로그래머가 익숙한 절차 적 스타일이 아닌 기능적 스타일 언어 라는 점을 감안할 때 저 와 같은 프로젝트를 시작하는 사람 에게는 제가 한 길을 따라 가거나 XSLT를 사용하는 것이 좋습니다. ?

답변

XSLT의 장점 :

  • XML에 고유 한 도메인이므로 예를 들어 출력에서 ​​리터럴 XML을 인용 할 필요가 없습니다.
  • 정규식이 문자열을 쿼리하는 좋은 방법이 될 수있는 것과 같은 방식으로 DOM을 쿼리하는 좋은 방법이 될 수있는 XPath / XQuery를 지원합니다.
  • 기능적 언어.

XSLT의 단점 :

  • 외설적으로 장황 할 수 있습니다. 리터럴 XML을 인용 할 필요가 없습니다. 이는 코드를 인용해야한다는 것을 의미합니다. 그리고 예쁜 방법이 아닙니다. 그러나 다시 말하지만 일반적인 SSI보다 훨씬 나쁘지는 않습니다.
  • 대부분의 프로그래머가 당연하게 여기는 특정 작업을 수행하지 않습니다. 예를 들어 문자열 조작은 귀찮은 일이 될 수 있습니다. 이로 인해 초보자가 코드를 디자인 한 다음 웹에서 기능을 구현하는 방법에 대한 힌트를 미친 듯이 검색 할 때 “불운 한 순간”이 발생할 수 있습니다.
  • 기능적 언어.

절차 적 동작을 얻는 한 가지 방법은 여러 변환을 함께 연결하는 것입니다. 각 단계 후에는 해당 단계의 변경 사항을 반영하는 작업 할 새로운 DOM이 있습니다. 일부 XSL 프로세서에는 한 번의 변환으로이를 효과적으로 수행 할 수있는 확장 기능이 있지만 세부 사항을 잊어 버렸습니다.

따라서 코드가 대부분 출력이고 로직이 많지 않은 경우 XSLT는이를 표현하는 매우 깔끔한 방법이 될 수 있습니다. 논리가 많지만 XSLT에 내장 된 대부분의 양식이 있다면 (blah처럼 보이는 모든 요소를 ​​선택하고 각 출력에 대해 blah) 상당히 친숙한 환경 일 가능성이 높습니다. 항상 XML을 좋아한다면 XSLT 2를 사용하십시오.

그렇지 않으면, 선호하는 프로그래밍 언어에 XPath를 지원하는 좋은 DOM 구현이 있고 유용한 방식으로 문서를 작성할 수 있다면 XSLT를 사용하는 데 따른 이점이 거의 없다고 말하고 싶습니다. libxml2 및 gdome2에 대한 바인딩은 훌륭하게 수행되어야하며 잘 알고있는 범용 언어를 고수하는 것은 부끄러운 일이 아닙니다.

자체 개발 한 XML 파서는 일반적으로 불완전하거나 (이 경우 언젠가는 문제가 해결 될 것입니다) 또는 선반에서 얻을 수있는 것보다 훨씬 작지 않습니다 (이 경우 아마도 시간을 낭비하게 될 것입니다). 악의적 인 입력에 대해 심각한 보안 문제를 일으킬 수있는 기회가 많습니다. 당신이 그것을 통해 얻는 것을 정확히 알지 못한다면 하나를 쓰지 마십시오. XML이 제공하는 모든 것이 필요하지 않다면 입력 형식으로 XML보다 간단한 구문 분석기를 작성할 수 없다는 것은 아닙니다.

답변

너무 부정적입니다!

저는 XSLT를 몇 년 동안 사용해 왔으며 진정으로 그것을 좋아합니다. 당신이 깨달아야 할 핵심은 그것이 프로그래밍 언어가 아니라 템플릿 언어라는 것입니다 (이 점에서 나는 그것이 asp.net / spit보다 말할 수 없을 정도로 우월하다고 생각합니다).

XML은 구성 파일, 원시 데이터 또는 메모리 재현 등 오늘날 웹 개발의 사실상 데이터 형식입니다. XSLT 및 XPath는 데이터를 원하는 출력 형식으로 변환 할 수있는 매우 강력하고 효율적인 방법을 제공하여 프레젠테이션을 데이터에서 분리하는 MVC 측면을 즉시 제공합니다.

그런 다음 유틸리티 기능이 있습니다. 네임 스페이스 삭제, 이질적인 스키마 정의 인식, 문서 병합.

있어야 자신의 사내 방법을 개발보다 XSLT 처리하는 것이 더합니다. 최소한 XSLT는 표준이며 고용 할 수있는 것입니다. 만약 그것이 당신의 팀에 정말로 문제가된다면 그것은 당신의 팀 대부분이 XML로만 작업 할 수있게 해줄 것입니다.

실제 사용 사례 : 방금 시스템 전체에서 인 메모리 XML 문서를 처리하고 최종 사용자가 요청한대로 JSON, HTML 또는 XML로 변환하는 앱을 작성했습니다. Excel 데이터로 제공하라는 상당히 임의의 요청이있었습니다. 이전 동료가 비슷한 작업을 프로그래밍 방식으로 수행했지만 몇 개의 클래스 파일 모듈이 필요했고 서버에 MS Office가 설치되어 있어야했습니다! Excel에는 3 시간 만에 최소베이스 코드 영향을주는 새로운 기능인 XSD가 있습니다.

개인적으로 저는 이것이 제 경력에서 만난 가장 깨끗한 일 중 하나라고 생각하며, 모든 명백한 문제 (디버깅, 문자열 조작, 프로그래밍 구조)가 도구에 대한 잘못된 이해에 있다고 생각합니다.

분명히 나는 ​​그것이 “가치가있다”고 강력하게 믿는다.

답변

나는 XSLT를 생계로 가르치기 때문에 여기서 편견을 인정해야합니다. 그러나 제 학생들이 일하고있는 분야를 은폐 할 가치가 있습니다. 그들은 일반적으로 출판, 은행 및 웹의 세 그룹으로 나뉩니다.

지금까지의 많은 답변은 “웹 사이트를 만드는 데 좋지 않다”또는 “언어 X와 같지 않다”라고 요약 할 수 있습니다. 많은 기술 담당자가 기능 / 선언적 언어에 대한 노출없이 경력을 쌓습니다. 내가 가르 칠 때, 경험 많은 Java / VB / C / etc 사람들은 언어에 문제가있는 사람들입니다 (예를 들어, 변수는 절차 적 프로그래밍이 아닌 대수 의미의 변수입니다). 여기에 대답하는 많은 사람들이 있습니다. 저는 Java를 사용 해본 적이 없지만 그 때문에 언어를 비판하지 않을 것입니다.

많은 경우 웹 사이트를 만드는 데 부적절한 도구입니다. 범용 프로그래밍 언어가 더 좋을 수 있습니다. 저는 종종 매우 큰 XML 문서를 웹에 표시해야합니다. XSLT는 그렇게 간단합니다. 이 공간에서 내가 보는 학생들은 데이터 세트를 처리하고 웹에 표시하는 경향이 있습니다. XSLT는 확실히이 분야에서 적용 가능한 유일한 도구는 아닙니다. 그러나 많은 사람들이이를 위해 DOM을 사용하고 있으며 XSLT는 확실히 덜 고통 스럽습니다.

내가 보는 은행 학생은 일반적으로 DataPower 상자를 사용합니다. 이것은 XML 어플라이언스이며 서로 다른 XML 방언을 ‘말하는’서비스 사이에 위치하는 데 사용됩니다. 한 XML 언어에서 다른 XML 언어로의 변환은 XSLT에서 거의 사소한 일이며 이에 대한 내 과정에 참석하는 학생 수가 증가하고 있습니다.

내가 보는 마지막 학생들은 출판 배경에서 나왔다. 이 사람들은 XML로 된 방대한 문서를 가지고있는 경향이 있습니다. (저를 믿으십시오. 업계가 XML에 매우 익숙해 짐에 따라 출판이 진행되고 있습니다. 기술 출판은 수년 동안 존재 해 왔고 이제는 무역 출판이 이루어지고 있습니다). 이러한 문서를 처리해야합니다 (여기에서 ePub 로의 DocBook을 염두에 두어야합니다).

위의 누군가는 스크립트가 60 줄 미만인 경향이 있거나 다루기 어려워 진다고 언급했습니다. 다루기 힘들어지면 코더가 실제로 아이디어를 얻지 못했을 가능성이 있습니다. XSLT는 다른 많은 언어와는 매우 다른 사고 방식입니다. 마음가짐을 얻지 못하면 작동하지 않습니다.

그것은 확실히 죽어가는 언어가 아닙니다 (제가받는 일의 양이 그것을 말해줍니다). 지금은 마이크로 소프트가 XSLT 2의 (아주 늦게) 구현을 마칠 때까지 약간 ‘고착’되어 있습니다.하지만 여전히 거기에 있고 제 관점에서 보면 강해지는 것 같습니다.

답변

XSLT는 문서화 및 사용자가 사용할 수있는 복잡한 구성 설정에 광범위하게 사용됩니다.

문서화의 경우 XML 기반 형식 인 DocBook을 많이 사용합니다. 이렇게하면 파일이 일반 텍스트이기 때문에 모든 소스 코드와 함께 문서를 저장하고 관리 할 수 ​​있습니다. XSLT를 사용하면 자체 문서 형식을 쉽게 구축 할 수 있으므로 일반적인 방식으로 콘텐츠를 자동 생성하고 콘텐츠를 더 읽기 쉽게 만들 수 있습니다. 예를 들어 릴리스 노트를 게시 할 때 다음과 같은 XML을 만들 수 있습니다.

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

그런 다음 XSLT (위를 DocBook으로 변환)를 사용하면 버그 ID가 자동으로 버그 추적기에 연결되고 버그가 구성 요소별로 그룹화되고 모든 형식이 완벽하게 일관된 멋진 릴리스 노트 (일반적으로 PDF 또는 HTML)가 생성됩니다. . 그리고 위의 XML은 버그 추적기에 버전간에 변경된 사항을 쿼리하여 자동으로 생성 할 수 있습니다.

XSLT가 유용하다는 것을 알게 된 또 다른 곳은 실제로 핵심 제품입니다. 타사 시스템과 인터페이스 할 때 복잡한 HTML 페이지의 데이터를 처리해야하는 경우가 있습니다. HTML을 파싱하는 것은 추악하므로 TagSoup 과 같은 것을 통해 데이터를 공급합니다.(적절한 SAX XML 이벤트를 생성하여 본질적으로 HTML이 제대로 작성된 XML 인 것처럼 HTML을 처리 할 수있게 함) 그런 다음 XSLT를 실행하여 데이터를 실제로 작업 할 수있는 “알려진 안정적인”형식으로 전환 할 수 있습니다. . 변환을 XSLT 파일로 분리하면 HTML 형식이 변경 될 때 응용 프로그램 자체를 업그레이드 할 필요가 없습니다. 대신 최종 사용자가 XSLT 파일을 직접 편집하거나 전자 메일을 보낼 수 있습니다. 전체 시스템을 업그레이드 할 필요없이 업데이트 된 XSLT 파일입니다.

웹 프로젝트의 경우 오늘날 XSLT보다 뷰 측면을 처리하는 더 좋은 방법이 있지만 기술로서 XSLT를 확실히 사용하는 방법이 있습니다. 세상에서 사용하기 가장 쉬운 언어는 아니지만 확실히 죽지 않았으며 내 관점에서 볼 때 여전히 많은 좋은 용도가 있습니다.

답변

XSLT는 선언적 프로그래밍 언어 의 예입니다 .

선언적 프로그래밍 언어의 다른 예로는 정규식, Prolog 및 SQL이 있습니다. 이들 모두는 표현력이 뛰어나고 간결하며 일반적으로 설계된 작업에 대해 매우 잘 설계되고 강력합니다.

그러나 소프트웨어 개발자는 일반적으로 이러한 언어를 싫어합니다. 왜냐하면 일반적인 OO 또는 절차 적 언어와 너무 다르기 때문에 배우고 디버깅하기 어렵 기 때문입니다. 그들의 조밀 한 특성은 일반적으로 실수로 많은 손상을 입히는 것을 매우 쉽게 만듭니다.

따라서 XSLT는 데이터를 프레젠테이션에 병합하는 효율적인 메커니즘이지만 사용하기 쉬운 부서에서는 실패합니다. 나는 그것이 실제로 잡히지 않은 이유라고 믿습니다.

답변

표준이 새로 출시되었을 때 XSLT에 대한 모든 과대 광고를 기억합니다. ‘간단한’변환으로 전체 HTML UI를 구축 할 수 있다는 점에 대한 모든 흥분.

그것을 직시하자, 사용하기 어렵고, 디버그하기 거의 불가능하며, 종종 참을 수 없을 정도로 느립니다. 최종 결과는 거의 항상 기발하고 이상적이지 않습니다.

XSLT를 사용하는 것보다 내 다리를 더 빨리 갉아 먹을 것입니다. 여전히 위치가 있으며 간단한 변환 작업에 적합합니다.

답변

저는 XSLT (및 XQuery)를 다양한 작업에 광범위하게 사용했습니다. 빌드 프로세스의 일부로 C ++ 코드를 생성하고, 문서 주석에서 문서를 생성하고, 일반적으로 XML과 특히 XHTML을 많이 사용해야하는 응용 프로그램 내에서 . 특히 코드 생성기는 약 12 ​​개의 개별 파일에 분산 된 10,000 줄 이상의 XSLT 2.0 코드였습니다 (클라이언트 용 헤더, 원격 프록시 / 스텁, COM 래퍼, .NET 래퍼, ORM 등 많은 작업을 수행했습니다. 몇 개). 나는 언어를 잘 이해하지 못하는 다른 사람에게 물려 받았고, 결과적으로 오래된 부분은 상당히 엉망이었습니다. 그러나 우리가 작성한 최신 내용은 대부분 정상적이고 읽기 쉽게 유지되었지만이를 달성하는 데 특별한 문제는 기억 나지 않습니다. 확실히 C ++에서하는 것보다 어렵지 않았습니다.

버전에 대해 말하면 XSLT 2.0을 다루는 것은 확실히 당신을 제정신으로 유지하는 데 도움이되지만 1.0은 여전히 ​​더 간단한 변환에 적합합니다. 틈새 시장에서는 매우 편리한 도구이며 특정 도메인 별 기능 (가장 중요한 것은 템플릿 일치를 통한 동적 디스패치)에서 얻는 생산성과 일치하기 어렵습니다. XSLT의 XML 기반 구문의 단어성에도 불구하고 LINQ to XML (XML 리터럴이있는 VB에서도)에서 동일한 것이 일반적으로 몇 배 더 길었습니다. 그러나 처음에는 XML을 불필요하게 사용하기 때문에 종종 당연한 결함이 있습니다.

요약하자면 도구 상자에 포함 할 수있는 매우 유용한 도구이지만 매우 전문화 된 도구이므로 적절하고 의도 한 목적으로 사용하는 한 좋습니다. XSLT 2.0의 적절한 네이티브 .NET 구현이 있었으면합니다.