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

얼마 전, 저자가 콘텐츠 (교육 과정 자료)를 간단한 형식으로 작성한 다음 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 구현이 있었으면합니다.

XSLT (더 나은 대안이 부족한 경우)를 사용하지만 변환을 위해서만 사용합니다.

1. maven pom.xml 파일에서 대량 편집을 수행하기 위해 짧은 XSLT 변환을 작성합니다.

2. XMI (UML 다이어그램)에서 XML 스키마를 생성하는 변환 파이프 라인을 작성했습니다. 한동안 작동했지만 결국 너무 복잡 해져서 헛간 뒤에서 꺼내야했습니다.

3. XML 스키마를 리팩터링하기 위해 변환을 사용했습니다.

4. XSLT를 사용하여 실제 작업을 수행하는 XSLT를 생성하여 XSLT의 몇 가지 제한 사항을 해결했습니다. (런타임까지 알려지지 않은 네임 스페이스를 사용하여 출력을 생성하는 XSLT를 작성해 본 적이 있습니까?)

내가 시도한 다른 접근 방식보다 처리중인 XML을 라운드 트립하는 작업이 더 낫기 때문에 계속해서 다시 돌아옵니다. 불필요하게 손실되거나 XML을 오해하는 것처럼 보였습니다. XSLT는 불쾌하지만 산소를 사용하면 견딜 수 있습니다.

즉, 저는 Clojure (a lisp)를 사용하여 XML 변환을 수행하는 방법을 조사 하고 있지만, 그 접근 방식이 제게 이익을 가져다 줄지 아직 충분히 알지 못했습니다.

개인적으로 저는 완전히 다른 맥락에서 XSLT를 사용했습니다. 당시 제가 작업하던 컴퓨터 게임은 XML을 사용하여 정의 된 수많은 UI 페이지를 사용했습니다. 릴리스 직후 주요 리팩터링 중에 이러한 XML 문서의 구조를 변경하고 싶었습니다. 우리는 게임의 입력 형식이 훨씬 더 나은 스키마 인식 구조를 따르도록 만들었습니다.

XSLT는 이전 형식-> 새 형식에서이 번역을위한 완벽한 선택으로 보였습니다. 2 주 만에 수백 페이지를 이전에서 새 페이지로 전환했습니다. 또한 UI 페이지의 레이아웃에 대한 많은 정보를 추출하는 데 사용할 수있었습니다. 비교적 쉽게 XSLT를 사용하여 스키마 정의에 쓰는 구성 요소가 내장 된 목록을 만들었습니다.

또한 C ++ 배경에서 왔기 때문에 마스터하기에 매우 재미 있고 흥미로운 언어였습니다.

XML을 한 형식에서 다른 형식으로 변환하는 도구로서 환상적이라고 생각합니다. 그러나 XML을 입력으로 사용하고 Something을 출력하는 알고리즘을 정의하는 유일한 방법은 아닙니다 . 알고리즘이 충분히 복잡한 경우 입력이 XML이라는 사실은 선택한 도구와 관련이 없습니다. 즉, C ++ / Python / 무엇이든 직접 굴려보세요.

귀하의 예에 따라 가장 좋은 아이디어는 비즈니스 논리를 따르는 XML-> XML 변환을 만드는 것입니다. 다음으로 서식 만 알고 영리하지 않은 XSLT 변환기를 작성하십시오. 그것은 좋은 중간 지점이 될 수 있지만 그것은 당신이하는 일에 전적으로 달려 있습니다. 출력에 XSLT 변환기가 있으면 인쇄 가능, 모바일 등의 대체 출력 형식을 더 쉽게 만들 수 있습니다.

네, 많이 사용합니다. 다른 xslt 파일을 사용하여 동일한 XML 소스를 사용하여 여러 다중 언어 (X) HTML 파일 (동일한 데이터를 다른 방식으로 표시), RSS 피드, Atom 피드, RDF 설명자 파일 및 사이트 맵 조각을 만들 수 있습니다. .

만병 통치약이 아닙니다. 잘하는 일도 있고 잘하지 않는 일도 있고, 프로그래밍의 다른 모든 측면과 마찬가지로 올바른 작업에 적합한 도구를 사용하는 것입니다. 도구 상자에 포함 할 가치가있는 도구이지만 적절한 경우에만 사용해야합니다.

나는 그것을 튀어 나오는 것이 좋습니다. 특히 XSLT 용 편집,보기 및 디버깅 도구가 내장 된 Visual Studio를 사용하는 경우.

예, 배우는 동안 고통 스럽지만 대부분의 고통은 친숙 함과 관련이 있습니다. 언어를 배우면 고통이 줄어 듭니다.

W3schools에는 특히 가치가있는 두 개의 기사가 있습니다. http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

XSLT는 작업하기가 매우 어렵다는 것을 알았습니다.

나는 당신이 설명하는 것과 다소 유사한 시스템에서 작업 한 경험이 있습니다. 우리 회사는 "중간 계층"에서 반환하는 데이터가 XML로되어 있고 페이지가 XHTML이 될 수도있는 HTML로 렌더링되어야한다고 언급했으며 XSL이 XML 간의 변환을위한 표준이라고 들었습니다. 형식. 그래서 "아키텍트"(즉, 깊이있는 디자인 생각을 생각하지만 코드를 작성하지 않는 사람들을 의미 함)는 디스플레이를 위해 데이터를 XHTML로 변환하는 XSLT 스크립트를 작성하여 프론트 티어를 구현하기로 결정했습니다.

선택은 비참한 것으로 판명되었습니다. XSLT는 작성하는 데 어려움이 있습니다. 그래서 우리의 모든 페이지는 작성하고 유지하기가 어려웠습니다. JSP (Java에 있음) 또는 출력 형식 (HTML)에 대해 한 종류의 마크 업 (각괄호)과 다른 종류의 마크 업 (예 : <% ...)을 사용하는 유사한 접근 방식을 사용하는 것이 훨씬 더 좋았을 것입니다. %>)는 메타 데이터입니다. XSLT에서 가장 혼란스러운 점은 XML로 작성되었고 XML에서 XML로 변환된다는 것입니다. 세 가지 다른 XML 문서를 모두 마음 속에 그대로 유지하는 것은 매우 어렵습니다.

상황은 약간 다릅니다. 내가 한 것처럼 XSLT에서 각 페이지를 작성하는 대신 XSLT (템플릿에서 표시로 변환하는 코드)로 한 비트의 코드 만 작성하면됩니다. 그러나 당신은 내가했던 것과 같은 종류의 어려움에 빠진 것 같습니다. 당신이하고있는 것처럼 간단한 XML 기반 DSL (도메인 특정 언어)을 해석하려는 시도는 XSLT의 강점 중 하나가 아니라고 말하고 싶습니다. (일을 할 수는 있지만 ... 결국 튜링 완료!)

그러나 만약 당신이 가진 것이 더 간단하다면 : 당신은 하나의 XML 형식으로 된 데이터를 가지고 있고 그것에 대한 간단한 변경을 원했습니다.-전체 페이지 설명 DSL이 아니라 몇 가지 간단한 간단한 수정을 원했다면 XSLT는 그 목적을위한 훌륭한 도구입니다. 선언적 (절차 적 아님) 특성은 실제로 그 목적에 대한 이점입니다.

-마이클 첨 사이드

XSLT는 작업하기 어렵지만 일단 정복하면 DOM과 스키마에 대해 매우 철저하게 이해하게됩니다. XPath도 있다면 함수형 프로그래밍을 배우는 중이며 문제 해결에 대한 새로운 기술과 방법에 노출 될 것입니다. 어떤 경우에는 연속적인 변환이 절차 적 솔루션보다 더 강력합니다.

사용자 지정 MVC 스타일 프런트 엔드를 위해 XSLT를 광범위하게 사용합니다. 모델은 xml 직렬화가 아닌 xml로 "직렬화"된 다음 xslt를 통해 html로 변환됩니다. ASP.NET에 비해 장점은 XPath와의 자연스러운 통합과보다 엄격한 형식 요구 사항에 있습니다 (대부분의 다른 언어보다 xslt에서 문서 구조에 대해 추론하기가 훨씬 쉽습니다).

안타깝게도 언어에는 몇 가지 제한 사항 (예 : 다른 변환의 출력을 변환하는 기능)이 포함되어있어 작업하는 데 때때로 좌절감을 느낍니다.

그럼에도 불구하고 쉽게 달성 할 수 있고 강력하게 시행되는 관심사 분리는 현재 다른 기술이 제공하는 것이 아니라 문서 변환의 경우 여전히 권장하는 것입니다.

저는 2004 년에 매우 다른 DB 시스템 간의 통합 프로젝트에서 XML, XSD 및 XSLT를 사용했습니다. XSD와 XSLT를 처음부터 배워야했지만 어렵지 않았습니다. 이러한 도구의 가장 큰 장점은 XSD 및 XSLT를 사용하여 XML 문서의 유효성을 검사 / 검증 한 다음 변환하는 데이터 독립적 인 C ++ 코드를 작성할 수 있다는 것입니다. 데이터 형식을 변경하고 Xerces 라이브러리를 사용하는 C ++ 코드가 아닌 XSD 및 XSLT 문서를 변경하십시오.

관심을 위해 : 기본 XSD는 150KB이고 XSLT의 평균 크기는 <5KB IIRC입니다.

또 다른 큰 이점은 XSD가 XSLT의 기반이되는 사양 문서라는 것입니다. 두 사람은 조화롭게 작동합니다. 그리고 요즘 소프트웨어 개발에서 사양은 드뭅니다.

선언적 특성 XSD 및 XSLT를 배우는 데 너무 많은 어려움이 없었지만 다른 C / C ++ 프로그래머가 선언적 방식에 적응하는 데 큰 문제가 있음을 발견했습니다. 그들이 그것을 보았을 때, 아 절차 상 그들은 중얼 거 렸습니다. 이제 내가 이해합니다! 그리고 그들은 절차 적 XSLT를 작성하기 위해 (말장난?) 진행했습니다! 문제는 XPath를 배우고 XML의 축을 이해해야한다는 것입니다. C ++를 작성할 때 OO를 사용하기로 조정 한 예전 C 프로그래머를 생각 나게합니다.

저는 이러한 도구를 사용하여 데이터 구조 수정의 가장 근본적인 부분을 제외하고는 모두 분리 된 작은 C ++ 코드베이스를 작성할 수 있었고 후자는 DB 구조 변경이었습니다. 다른 언어보다 C ++를 선호하지만 소프트웨어 프로젝트의 장기적인 실행 가능성을 높이기 위해 유용하다고 생각되는 것을 사용할 것입니다.

저는 XSLT가 좋은 아이디어라고 생각했습니다. 나는 그것이 의미 입니다 좋은 생각.

실패하는 곳은 실행입니다.

시간이 지남에 따라 내가 발견 한 문제는 XML로 된 프로그래밍 언어는 단지 나쁜 생각이라는 것입니다. 그것은 모든 것을 뚫을 수 없게 만듭니다. 특히 XSLT는 배우고, 코딩하고, 이해하기가 매우 어렵다고 생각합니다. 기능적 측면에서 XML은 모든 것을 너무 혼란스럽게 만듭니다. 제 커리어에서 5 번 정도 배우려고했는데 그냥 달라 붙지 않습니다.

좋아요, 당신은 그것을 '도구'할 수 있습니다-부분적으로 디자인의 요점이라고 생각합니다-그러나 그것은 두 번째 실패입니다 : 시장에 나와있는 모든 XSLT 도구는 아주 간단합니다 ... 쓰레기입니다!

XSLT 사양 을 정의는 "다른 XML 문서로 XML 문서를 변환하는 언어"로 XSLT. XSLT 내에서 가장 기본적인 데이터 처리를하려고한다면 더 나은 솔루션이있을 것입니다.

또한 XSLT의 데이터 처리 기능은 사용자 지정 확장 기능을 사용하여 .NET에서 확장 할 수 있습니다.

• MSDN 문서
• CSharpFriends : 튜토리얼

회사의 온라인 문서 시스템을 유지하고 있습니다. 작성자는 SGML (언어와 같은 xml)로 문서를 작성합니다. 그런 다음 SGML은 XSLT와 결합되어 HTML로 변환됩니다.

이를 통해 코딩없이 문서 레이아웃을 쉽게 변경할 수 있습니다. XSLT를 변경하기 만하면됩니다.

이것은 우리에게 잘 작동합니다. 우리의 경우 읽기 전용 문서입니다. 사용자가 문서와 상호 작용하지 않습니다.

또한 XSLT를 사용하면 문제 도메인 (HTML)에 더 가깝게 작업 할 수 있습니다. 나는 항상 좋은 생각이라고 생각합니다.

마지막으로 현재 시스템이 작동하면 그대로 두십시오. 나는 당신의 기존 코드를 폐기하는 것을 결코 제안하지 않을 것입니다. 처음부터 시작하는 경우 XSLT를 사용하지만 귀하의 경우에는 보유한 것을 사용합니다.

그것은 당신이 그것을 필요로하는 것에 달려 있습니다. 그것의 주요 강점은 변환의 쉬운 유지 관리이며, 자신의 파서를 작성하면 일반적으로 그것을 제거합니다. 그렇긴하지만 때로는 시스템이 작고 단순하며 실제로 "멋진"솔루션이 필요하지 않습니다. 코드 기반 빌더가 다른 코드를 변경하지 않고도 교체 할 수있는 한 큰 문제는 아닙니다.

XSL의 추함은 예, 추합니다. 예, 익숙해지는 데 약간의 시간이 걸립니다. 그러나 일단 익숙해지면 (IMO는 오래 걸리지 않을 것입니다) 실제로 순조로운 항해입니다. 컴파일 된 변환은 내 경험상 매우 빠르게 실행되며 확실히 디버그 할 수 있습니다.

나는 여전히 XSLT가 유용 할 수 있다고 믿지만 그것은 추악한 언어이며 끔찍한 읽을 수없고 유지 보수 할 수없는 엉망으로 이어질 수 있습니다. 부분적으로는 XML이 "언어"를 구성 할 수있을만큼 사람이 읽을 수 없기 때문이고, 부분적으로는 XSLT가 선언적과 절차 적 사이에 갇혀 있기 때문입니다. 그렇다고해서 정규 표현식으로 비교를 그릴 수 있다고 생각하지만 간단하고 잘 정의 된 문제에 유용합니다.

대체 접근 방식을 사용하고 코드에서 XML을 구문 분석하는 것은 똑같이 불쾌 할 수 있으며 XML을 객체로 직접 변환하는 일종의 XML 마샬링 / 바인딩 기술 (예 : Java의 JiBX)을 사용하고 싶습니다.

XSLT를 선언적 스타일로 사용할 수 있다면 (선언적 언어라는 데 전적으로 동의하지는 않지만) 유용하고 표현 적이라고 생각합니다.

OO 언어 (제 경우에는 C #)를 사용하여 데이터 / 처리 계층을 처리하지만 HTML이 아닌 XML을 출력하는 웹 앱을 작성했습니다. 그런 다음 클라이언트에서 데이터 API로 직접 사용하거나 XSLT에서 HTML로 렌더링 할 수 있습니다. C #이이 용도와 구조적으로 호환되는 XML을 출력했기 때문에 모든 것이 매우 매끄럽고 프레젠테이션 로직이 선언적으로 유지되었습니다. C #에서 태그를 보내는 것보다 따르고 변경하는 것이 더 쉬웠습니다.

그러나 XSLT 수준에서 더 많은 처리 논리가 필요하기 때문에 기능 스타일을 "가져올"경우에도 복잡하고 장황 해집니다.

물론 요즘에는 아마도 RESTful 인터페이스를 사용하여 웹 앱을 작성했을 것입니다. JSON과 같은 데이터 "언어"가 전통적으로 XML이 XSLT에 의해 변형 된 영역에서 견인력을 얻고 있다고 생각합니다. 그러나 현재 XSLT는 여전히 중요하고 유용한 기술입니다.

XSLT에서 많은 시간을 보냈고 어떤 상황에서는 유용한 도구이지만 확실히 모든 것을 고치는 것은 아닙니다. 기계가 읽을 수있는 XML 입력 / 출력을위한 데이터 변환에 사용될 때 B2B 용도로 매우 잘 작동합니다. 나는 당신이 한계에 대한 진술에서 잘못된 길을 가고 있다고 생각하지 않습니다. 저를 가장 좌절시킨 것 중 하나는 XSLT 구현의 뉘앙스였습니다.

사용 가능한 다른 마크 업 언어를 살펴 봐야 할 것입니다. 저는 Jeff가 Stack Overflow에 관한 바로이 주제에 대한 기사를 작성했다고 믿습니다.

HTML은 인간적인 마크 업 언어입니까?

나는 그가 쓴 것을 볼 것입니다. 당신은 아마도 당신이 원하는 것을 "즉석에서"수행하는 소프트웨어 패키지를 찾을 수있을 것이고, 또는 처음부터 당신 자신의 것을 작성하는 대신 적어도 아주 가까이에있을 것입니다.

저는 현재 공개 사이트에서 데이터를 스크랩하는 작업을하고 있습니다 (예, 압니다). 고맙게도 xhtml을 준수하므로 xslt를 사용하여 필요한 데이터를 수집 할 수 있습니다. 결과 솔루션은 읽기 쉽고 깔끔하며 필요할 경우 쉽게 변경할 수 있습니다. 완전한!

전에 XSLT를 사용했습니다. 6 개의 .xslt 파일 그룹 (하나의 큰 파일에서 리팩토링 됨)은 C #으로 다시 작성하기 전에 약 2750 줄이었습니다. C # 코드는 현재 많은 논리를 포함하는 4000 줄입니다. XSLT로 작성하는 데 필요한 작업에 대해 생각하고 싶지도 않습니다.

내가 포기한 지점은 XPATH 2.0이 없다는 사실이 내 발전에 큰 타격을 준다는 것을 깨달았을 때입니다.

세 가지 질문에 답하려면 :

1. 몇 년 전에 XSLT를 사용했습니다.
2. XSLT가 특정 상황에서 올바른 솔루션이 될 수 있다고 생각합니다. (절대 절대 말 하지마)
3. 나는 그것이 '단순한'변형에 주로 유용하다는 당신의 평가에 동의하는 경향이 있습니다. 하지만 XSLT를 잘 이해하는 한 웹 사이트를 HTML로 변환 한 XML로 게시하는 것과 같은 더 큰 작업에 사용하는 경우가 있다고 생각합니다.

많은 개발자들이 XSLT를 싫어하는 이유는 XSLT가 기반으로하는 근본적으로 다른 패러다임을 이해하지 못하기 때문이라고 생각합니다. 그러나 최근 함수형 프로그래밍에 대한 관심으로 인해 XSLT가 복귀하는 것을 볼 수 있습니다.

xslt가 정말 빛나는 곳은 보고서를 생성하는 것입니다. 보고서 데이터를 xml 파일로 내보내는 첫 번째 단계와 xslt를 사용하여 xml에서 시각적 보고서를 생성하는 두 번째 단계로 이루어진 2 단계 프로세스를 발견했습니다. 이를 통해 필요한 경우 유효성 검사 메커니즘으로 원시 데이터를 유지하면서 멋진 시각적 보고서를 만들 수 있습니다.

이전 회사에서는 XML과 XSLT로 많은 일을했습니다. XML과 XSLT가 모두 큽니다.

예, 학습 곡선이 있지만 XML을 처리 할 수있는 강력한 도구가 있습니다. 그리고 XSLT에서 XSLT를 사용할 수도 있습니다 (때로는 유용 할 수 있음).

성능도 문제 (매우 큰 XML의 경우)이지만 스마트 XSLT를 사용하여 문제를 해결하고 (생성 된) XML로 일부 전처리를 수행 할 수 있습니다.

XSLT에 대한 지식이있는 사람은 완성 된 제품이 컴파일되지 않았기 때문에 외관을 변경할 수 있습니다.

저는 개인적으로 XSLT를 좋아하고 단순화 된 구문 을 보여주고 싶을 수 있습니다 (명시 적 템플릿이없고 XSLT 태그가 몇 개있는 일반적인 오래된 HTML 파일).하지만 모든 사람을위한 것은 아닙니다.

작성자에게 간단한 Wiki 또는 Markdown 인터페이스를 제공하고 싶을 수도 있습니다. 이를위한 라이브러리도 있으며 XSLT가 작동하지 않으면 XML도 작동하지 않을 수 있습니다.

XSLT는 xml 변환의 모든 것이 아닙니다. 그러나 주어진 정보를 바탕으로 문제에 대한 최선의 해결책이되었는지 또는 더 효율적이고 유지 관리 가능한 다른 접근 방식이 있는지 판단하는 것은 매우 어렵습니다. 저자가 간단한 형식으로 콘텐츠를 입력 할 수 있다고 하셨나요? 어떤 형식인가요? 텍스트 상자? 어떤 종류의 HTML로 변환 했습니까? XSLT가 작업에 적합한 도구인지 판단하려면이 변환의 기능을 더 자세히 아는 것이 도움이 될 것입니다.

XML 문서의 트리 구조를 변경하기 위해서만 XSLT를 사용하는 것을 좋아합니다. 텍스트 처리와 관련된 모든 작업을 수행하고이를 XML 문서에 XSLT를 적용하기 전이나 후에 실행할 수있는 사용자 지정 스크립트에 관련시키는 것이 번거 롭습니다.

XSLT 2.0에는 더 많은 문자열 함수가 포함되어 있지만 언어에 적합하지 않으며 XSLT 2.0 구현이 많지 않다고 생각합니다.