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

https://stackoverflow.com/questions/78716

xml
xslt

09-06-2019
|

문제

얼마 전 저는 작성자가 자신의 콘텐츠(교육 과정 자료)를 단순화된 형식으로 작성한 다음 XSLT를 통해 HTML로 변환할 수 있도록 html과 같은 XML 스키마를 디자인하는 프로젝트를 시작했습니다.한동안 가지고 놀아서 아주 기본적인 수준까지 도달했지만, 내가 직면한 한계(내 지식의 한계였을 수도 있음)에 너무 짜증이 났고, 버리라고 제안하는 블로그를 읽었을 때 XSLT를 선택하고 선택한 언어로 XML-to-What 구문 분석기를 작성하면 열성적으로 그것에 뛰어들었고 훌륭하게 작동했습니다.

나는 지금까지도 계속 노력하고 있다(실제로 SO에서 플레이하는 대신 지금 당장 작업을 하고 있어야 합니다.) 그리고 XSLT를 버리는 결정이 좋은 결정이었다고 생각하게 만드는 것들이 점점 더 많아지고 있습니다.

나는 XSLT가 수용된 표준이라는 점에서 그 자리를 차지하고 모든 사람이 자신의 통역사를 작성하는 경우 그 중 90%가 결국 더데일리WTF.그러나 그것이라는 점을 감안할 때 함수형 언어 대부분의 프로그래머에게 익숙한 절차적 스타일 대신에 저와 같은 프로젝트를 시작하는 사람에게는 내가 했던 길을 따라가도록 권유하시겠습니까, 아니면 XSLT를 사용하여 고집하시겠습니까??

해결책

XSLT의 장점:

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

XSLT의 단점:

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

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

따라서 코드가 대부분 출력이고 논리가 많지 않은 경우 XSLT는 이를 표현하는 매우 깔끔한 방법이 될 수 있습니다.논리는 많지만 대부분 XSLT에 내장된 양식(어쩌고 보이는 모든 요소를 선택하고 각각의 출력에 대해 어쩌고 하는 경우)이 있다면 상당히 친숙한 환경이 될 가능성이 높습니다.항상 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에 XSD가 있는 것으로 나타났습니다.3시간 안에 베이스코드에 미치는 영향을 최소화하는 새로운 기능.

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

분명히 나는 그것이 "그럴 만한 가치가 있다"고 굳게 믿습니다.

나는 생계를 위해 XSLT를 가르치기 때문에 여기에 편견을 인정해야 합니다.하지만 학생들이 일하는 영역을 다루는 것은 가치가 있을 수 있습니다.그들은 일반적으로 세 그룹으로 나뉩니다.출판, 은행, 웹.

지금까지의 답변 중 상당수는 "웹 사이트를 만드는 데 좋지 않습니다" 또는 "언어 X와는 전혀 다릅니다"로 요약될 수 있습니다.많은 기술 인력은 기능적/선언적 언어를 접하지 않고 경력을 쌓습니다.제가 가르칠 때 경험이 풍부한 Java/VB/C/etc 사람들은 언어에 문제가 있는 사람들입니다(예를 들어 변수는 절차적 프로그래밍이 아닌 대수학 의미의 변수입니다).여기에 답변하는 많은 사람들이 있습니다. 저는 Java를 사용해본 적이 없지만 그 때문에 언어를 비판할 생각은 없습니다.

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

내가 본 은행 학생들은 일반적으로 DataPower 상자를 사용합니다.이것은 XML 어플라이언스이며 다양한 XML 방언을 '말하는' 서비스 사이에 위치하는 데 사용됩니다.XSLT에서는 하나의 XML 언어에서 다른 언어로의 변환이 거의 쉽지 않으며 이에 대한 내 강좌에 참석하는 학생 수가 증가하고 있습니다.

내가 본 마지막 학생 세트는 (나와 같은) 출판 배경 출신입니다.이 사람들은 XML로 된 엄청난 양의 문서를 갖고 있는 경향이 있습니다. (내 말을 믿으십시오. 출판 업계는 XML을 매우 많이 사용하고 있습니다. 기술 출판은 수년 동안 거기에 있었고 무역 출판도 이제 거기에 이르렀습니다.)이러한 문서는 처리되어야 합니다(여기에서는 DocBook에서 ePub으로 이동하는 것이 중요합니다).

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

확실히 죽어가는 언어는 아닙니다. (내가 하는 일의 양을 보면 알 수 있습니다.)지금은 Microsoft가 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가 유용하다고 생각하는 또 다른 부분은 실제로 핵심 제품입니다.때때로 제3자 시스템과 인터페이스할 때 복잡한 HTML 페이지의 데이터를 처리해야 하는 경우가 있습니다.HTML을 구문 분석하는 것은 보기 흉하므로 다음과 같은 방법으로 데이터를 공급합니다. 태그수프 (적절한 SAX XML 이벤트를 생성하여 본질적으로 HTML이 제대로 작성된 XML인 것처럼 처리할 수 있게 함) 그런 다음 이에 대해 일부 XSLT를 실행하여 데이터를 실제로 작업할 수 있는 "알려진 안정적인" 형식으로 바꿀 수 있습니다. .해당 변환을 XSLT 파일로 분리함으로써 HTML 형식이 변경되는 경우 애플리케이션 자체를 업그레이드할 필요가 없으며 대신 최종 사용자가 XSLT 파일을 직접 편집하거나 이메일을 보낼 수 있음을 의미합니다. 전체 시스템을 업그레이드할 필요 없이 업데이트된 XSLT 파일입니다.

웹 프로젝트의 경우 현재 XSLT보다 뷰 측면을 처리하는 더 나은 방법이 있지만 기술로는 확실히 XSLT를 사용하는 방법이 있습니다.세상에서 사용하기 가장 쉬운 언어는 아니지만 확실히 죽은 언어는 아니며 내 관점에서는 여전히 유용하게 사용될 수 있는 언어가 많이 있습니다.

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

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

그러나 소프트웨어 개발자는 일반적으로 이러한 언어를 싫어합니다. 왜냐하면 이러한 언어는 주류 OO 또는 절차적 언어와 너무 다르기 때문에 배우고 디버깅하기 어렵기 때문입니다.그들의 컴팩트한 특성으로 인해 일반적으로 실수로 많은 피해를 입히기가 매우 쉽습니다.

따라서 XSLT는 데이터를 프레젠테이션에 병합하는 효율적인 메커니즘이지만 사용 편의성 측면에서는 실패합니다.나는 이것이 실제로 인기를 얻지 못한 이유라고 믿습니다.

표준이 새로 출시되었을 때 XSLT에 대한 모든 과대광고를 기억합니다.'간단한' 변환을 통해 전체 HTML UI를 구축할 수 있다는 사실에 대한 모든 즐거움이 있습니다.

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

XSLT를 사용하는 것보다 더 빨리 다리를 갉아먹을 것입니다. 더 나은 방법이 있기는 하지만요.여전히 그 자리가 있고 간단한 변환 작업에 좋습니다.

저는 빌드 프로세스의 일부로 C++ 코드를 생성하고, 문서 주석에서 문서를 생성하고, 일반적으로 XML, 특히 XHTML을 사용하여 작업해야 하는 응용 프로그램 내에서 다양한 작업에 XSLT(및 XQuery)를 광범위하게 사용했습니다. .특히 코드 생성기는 약 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를 사용하지만 프레젠테이션용이 아니라 변환용으로만 사용합니다.

저는 maven pom.xml 파일을 대량으로 편집하기 위해 짧은 XSLT 변환을 작성합니다.
나는 XMI(UML 다이어그램)에서 XML 스키마를 생성하기 위한 변환 파이프라인을 작성했습니다.한동안 효과가 있었지만 결국 너무 복잡해져서 헛간 뒤로 가져와야 했습니다.
저는 변환을 사용하여 XML 스키마를 리팩터링했습니다.
실제 작업을 수행하기 위해 XSLT를 생성하는 데 이를 사용하여 XSLT의 몇 가지 제한 사항을 해결했습니다.(런타임까지 알려지지 않은 네임스페이스를 사용하여 출력을 생성하는 XSLT를 작성해 본 적이 있습니까?)

불필요하게 손실이 있거나 단순히 XML을 오해하는 것처럼 보였던 다른 접근 방식보다 처리 중인 XML을 더 잘 왕복하는 작업을 수행하기 때문에 계속해서 다시 돌아옵니다.XSLT는 불쾌하지만 산소 견딜 수 있게 만들어줍니다.

즉, 다음을 사용하여 조사 중입니다. 클로저 (LISP) XML 변환을 수행하지만 해당 접근 방식이 나에게 이점을 가져다줄지 아직 충분히 알지 못했습니다.

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

XSLT는 이전 형식 -> 새 형식을 번역하는 데 완벽한 선택인 것 같습니다.2주 만에 수백 페이지에 달하는 기존 페이지를 새 페이지로 전환하는 작업이 완료되었습니다.또한 이를 사용하여 UI 페이지 레이아웃에 대한 많은 정보를 추출할 수 있었습니다.나는 상대적으로 쉽게 포함된 구성 요소 목록을 만든 다음 XSLT를 사용하여 스키마 정의에 기록했습니다.

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

나는 XML을 한 형식에서 다른 형식으로 변환하는 도구로서 환상적이라고 생각합니다.그러나 이것이 XML을 입력으로 사용하고 출력하는 알고리즘을 정의하는 유일한 방법은 아닙니다. 무엇.알고리즘이 충분히 복잡하다면 입력이 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 사양 XSLT를 "XML 문서를 다른 XML 문서로 변환하는 언어"로 정의합니다.XSLT 내에서 가장 기본적인 데이터 처리 이외의 작업을 수행하려는 경우 더 나은 솔루션이 있을 수 있습니다.

또한 사용자 정의 확장 기능을 사용하여 XSLT의 데이터 처리 기능을 .NET에서 확장할 수 있다는 점도 주목할 가치가 있습니다.

나는 우리 회사의 온라인 문서 시스템을 유지 관리하고 있습니다.작성자는 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이 없다는 것이 제 발전에 큰 타격을 입혔다는 것을 깨달았을 때입니다.

세 가지 질문에 답하려면:

저는 몇 년 전에 XSLT를 한 번 사용해 본 적이 있습니다.
저는 XSLT가 특정 상황에서 올바른 솔루션이 될 수 있다고 믿습니다.(절대 말하지 마세요)
나는 이것이 '간단한' 변환에 주로 유용하다는 귀하의 평가에 동의하는 경향이 있습니다.하지만 XSLT를 잘 이해한다면 XML을 HTML로 변환하여 웹 사이트를 게시하는 것과 같은 더 큰 작업에 사용할 수 있는 경우가 있다고 생각합니다.

많은 개발자가 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 구현이 많지 않다고 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow