XSLT가 가치가 있습니까?

XSLT가 가치가 있습니까?

현재 상태로는 이 질문은 우리의 Q&A 형식에 맞지 않습니다.사실, 참고 자료 또는 전문 지식에 의해 답변이 뒷받침되기를 기대하지만, 이 질문은 토론, 주장, 여론 조사 또는 토론을 요청할 가능성이 높습니다.만약 이 질문이 개선되고 다시 열릴 수 있다고 생각한다면,안내를 받기 위해 헬프 센터를 방문합니다.

닫힘11년 전에.

얼마 전, 저는 저자들이 자신의 콘텐츠(교육과정 자료)를 단순화된 형식으로 작성할 수 있도록 html-esque XML 스키마를 설계하고 XSLT를 통해 HTML로 변환하는 프로젝트를 시작했습니다.저는 한동안 그것을 가지고 놀았고(힘들게) 아주 기본적인 수준까지 도달했지만, 제가 직면하고 있는 한계(제 지식의 한계였을지도 모릅니다)와 XSLT를 버리고 여러분이 선택한 언어로 여러분만의 XML-to-Whate parser를 쓰라고 제안하는 블로그를 읽었을 때,저는 열심히 그 일에 뛰어들었고, 그것은 훌륭하게 해결되었습니다.

저는 현재까지도 이 작업을 진행하고 있으며(실제로 SO에서 플레이하는 대신 현재 작업 중입니다), XSLT를 포기한 결정이 좋은 결정이었다는 생각이 들게 하는 점점 더 많은 것을 보고 있습니다.

XSLT는 인정되는 기준이라는 점에서 나름의 자리가 있다는 것을 알고 있고, 모든 사람들이 직접 통역사를 쓰고 있다면 90%가 The Daily에 들어가게 된다는 것을 알고 있습니다.WTF. 하지만 대부분의 프로그래머들이 익숙한 절차적 스타일이 아닌 기능적 스타일의 언어이기 때문에, 나와 같은 프로젝트를 시작하는 사람에게, 당신은 그들이 내가 했던 길을 가는 것을 추천하시겠습니까, 아니면 XSLT로 그것을 고수하시겠습니까?

너무 부정적이에요!

저는 XSLT를 몇 년 동안 사용해 왔고, 그것을 진심으로 좋아합니다.여러분이 깨달아야 할 핵심적인 것은 프로그래밍 언어가 아니라 템플릿 언어라는 것입니다(이 점에서 저는 asp.net /http:/http:/http:/http:/http://http://http://http://http://http:/.

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

그런 다음, 네임스페이스를 씻어내고, 서로 다른 스키마 정의를 인식하고, 문서를 병합하는 유틸리티 기능이 있습니다.

자체적으로 자체적인 방법을 개발하는 것보다 XSLT에 대처하는 것이 더 나을 것입니다.최소한 XSLT는 표준이고 고용할 수 있는 용도이며, 팀에 정말 문제가 될 경우 대부분의 팀이 XML로만 작업할 수 있도록 지원합니다.

실제 사용 사례:인메모리 XML 문서를 시스템 전체에서 처리하고 최종 사용자의 요청에 따라 JSON, HTML 또는 XML로 변환하는 앱을 작성했습니다.저는 엑셀 자료로 제공해달라는 요청을 꽤 무작위로 받았습니다.이전 동료가 프로그램적으로 비슷한 일을 했지만 몇 개의 클래스 파일 모듈이 필요했고 서버에 MS Office가 설치되어 있었습니다!Excel은 3시간 안에 기본 코드 영향을 최소화하는 새로운 기능인 XSD를 가지고 있는 것으로 나타났습니다.

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

분명히, 저는 그것이 "가치 있다"고 강력하게 믿고 있습니다.

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를 가르치기 때문에 여기서 편견을 인정해야 합니다.하지만 학생들이 일하는 곳을 가려줄 가치가 있을지도 모릅니다.그들은 일반적으로 출판, 은행 및 웹의 세 그룹으로 나뉩니다.

지금까지 나온 많은 답변들은 "웹사이트를 만드는 데 도움이 되지 않는다"거나 "언어 X와 전혀 다르다"로 요약될 수 있습니다.많은 기술자들이 기능적/선언적 언어에 노출되지 않고 경력을 쌓습니다.제가 수업을 할 때 언어에 문제가 있는 사람은 경험이 풍부한 자바/VB/C/ 등입니다(예를 들어 절차적 프로그래밍이 아닌 대수적 의미의 변수).많은 사람들이 여기에 답을 합니다. 저는 자바를 해본 적이 없지만 그것 때문에 굳이 언어를 비평하지는 않을 것입니다.

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

제가 보는 은행권 학생들은 일반적으로 데이터 파워 박스를 사용합니다.이것은 XML 어플라이언스이며 서로 다른 XML 방언을 '말하는' 서비스 사이에 위치하는 데 사용됩니다.XSLT에서 XML 언어에서 다른 언어로의 변환은 거의 미미하며, 이에 대한 강의에 참여하는 학생의 수가 증가하고 있습니다.

제가 보는 최종 학생들은 (저와 같은) 출판계 출신입니다.이러한 사람들은 XML로 된 방대한 문서를 보유하는 경향이 있습니다(제 생각에, 업계로서 출판이 XML에 매우 빠져들고 있습니다 - 기술 출판은 수년 동안 있어 왔고 무역 출판은 이제 시작되고 있습니다).이 문서들을 처리해야 합니다(DocBook to ePub이 여기에 떠오릅니다).

위의 누군가는 대본이 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이 제대로 작성된 것처럼 본질적으로 처리할 수 있게 해줍니다). 그러면 XSLT를 실행하여 데이터를 실제로 작업할 수 있는 "안정적으로 알려진" 형식으로 전환할 수 있습니다.이 변환을 XSLT 파일로 분리하면 HTML 형식이 변경되면 애플리케이션 자체를 업그레이드할 필요가 없으며, 최종 사용자가 XSLT 파일을 직접 편집하거나 전체 시스템을 업그레이드할 필요 없이 업데이트된 XSLT 파일을 이메일로 보낼 수 있습니다.

웹 프로젝트의 경우, 현재 XSLT보다 뷰 측면을 더 잘 처리할 수 있는 방법이 있지만, 기술적으로는 XSLT에 대한 용도가 분명히 있습니다.세상에서 가장 사용하기 쉬운 언어는 아니지만, 확실히 죽지는 않았고, 제 입장에서는 여전히 좋은 사용법이 많습니다.

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

선언 프로그래밍 언어의 다른 예로는 정규식, 프롤로그, SQL 등이 있습니다.이 모든 것들은 매우 표현력이 뛰어나고 콤팩트하며, 보통 자신이 설계한 작업에 적합하도록 매우 잘 설계되고 강력합니다.

그러나 소프트웨어 개발자들은 일반적으로 이러한 언어들을 싫어하는데, 그 이유는 보다 주류적인 OOO나 절차적인 언어들과는 너무 달라서 배우고 디버깅하기가 어렵기 때문입니다.그들의 콤팩트한 특성은 일반적으로 부주의로 많은 손상을 입히는 것을 매우 쉽게 만듭니다.

따라서 XSLT는 프레젠테이션에 데이터를 병합하는 효율적인 메커니즘이지만 사용 편의성 부서에서는 실패합니다.그래서 인기가 별로 없었던 것 같습니다.

저는 표준이 새로 나왔을 때 XSLT에 대한 모든 광고를 기억합니다.'간단한' 변환을 통해 전체 HTML UI를 구축할 수 있다는 것에 대한 모든 흥분.

실제로 사용하기 어렵고 디버깅이 거의 불가능하며 종종 참을 수 없을 정도로 느립니다.최종 결과는 거의 항상 변덕스럽고 이상적이지 못합니다.

XSLT를 사용하는 것보다 내 다리를 더 빨리 잘라버릴 것입니다. 더 나은 방법이 있을 때 말이죠.여전히 자리가 있고 단순한 변환 작업에 유용합니다.

저는 XSLT(그리고 XQuery)를 다양한 용도로 광범위하게 사용해 왔습니다. 빌드 프로세스의 일부로 C++ 코드를 생성하고, 문서 코멘트로부터 문서를 생성하며, 일반적으로 XML과 XHTML로 작업해야 하는 애플리케이션 내에서 특히 많이 사용했습니다.특히 코드 생성기는 십여 개의 개별 파일에 퍼져 있는 10,000 줄이 넘는 XSLT 2.0 코드를 가지고 있었습니다(클라이언트용 헤더, 원격 프록시/스텁, COM 래퍼 등).NET 포장지, ORM - 몇 가지 예를 들어보겠습니다.언어를 잘 이해하지 못하는 다른 남자에게 물려주고, 오래된 것들은 결과적으로 꽤 엉망이 되었습니다.그러나 우리가 작성한 새로운 내용은 대부분 제정신으로 읽을 수 있도록 유지되었으며, 이를 달성하는 데 있어 특별한 문제는 기억하지 못합니다.그것은 확실히 C++를 위해 그것을 하는 것보다 더 어렵지 않았습니다.

버전에 대해 말하자면, XSLT 2.0을 다루는 것은 제정신을 유지하는 데 확실히 도움이 되지만, 1.0은 더 간단한 변환을 위해 여전히 괜찮습니다.틈새 시장에서 매우 편리한 도구이며 특정 도메인별 기능(가장 중요한 것은 템플릿 매칭을 통한 동적 디스패치)에서 얻을 수 있는 생산성은 일치하기 어렵습니다.XSLT의 XML 기반 구문의 단어성이 인식되었음에도 불구하고, LINQ에서 XML로의 동일한 작업(심지어 XML 리터럴을 사용하는 VB에서도)은 대개 몇 배 더 길었습니다.그러나 처음부터 XML을 불필요하게 사용하기 때문에 불필요한 플랙이 발생하는 경우가 많습니다.

요약하자면, 도구 상자에 가지고 있으면 엄청나게 유용한 도구이지만, 매우 전문적인 도구이므로, 도구를 적절히 사용하고 의도된 목적으로 사용하기만 하면 좋습니다.제대로 된 원주민이 있었으면 좋겠어요.XSLT 2.0의 NET 구현.

XSLT를 사용하지만 프레젠테이션용이 아니라 변환용으로 사용합니다.

1. 나는 우리가 만든 pom.xml 파일을 대량 편집하기 위해 짧은 XSLT 변환을 씁니다.

2. XMI(UML Diagram)에서 XML 스키마를 생성하기 위한 변환 파이프라인을 작성했습니다.한동안은 효과가 있었지만, 마침내 너무 복잡해져서 헛간 뒤에서 꺼내야 했습니다.

3. XML 스키마를 재분류하기 위해 변환을 사용했습니다.

4. 실제 작업을 수행하기 위해 XSLT를 생성하는 데 사용하여 XSLT의 몇 가지 제한 사항을 해결했습니다. (실행시간까지 알 수 없는 네임스페이스를 사용하여 출력을 생성하는 XSLT를 작성하려고 시도한 적이 있습니까?)

제가 시도한 다른 접근 방식보다 XML을 라운드 트립하는 것이 더 잘 작동하기 때문에 계속해서 XSLT로 돌아옵니다. XSLT는 불쾌하지만 산소를 사용하면 견딜 수 있다는 것을 알게 되었습니다.

그렇지만, XML 변환을 수행하기 위해 Clojure(alisp)를 사용하는 방법을 조사하고 있지만, 아직 그 방법이 이점을 가져다 줄지는 알 수 없습니다.

개인적으로 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를 위한 편집, 보기 및 디버깅 툴을 내장한 비주얼 스튜디오를 사용하는 경우에는 더욱 그렇습니다.

네, 배우는 동안의 고통이지만 대부분의 고통은 익숙함과 관련된 것입니다.언어를 배우면서 고통은 줄어들게 됩니다.

W3 학교에는 특별한 가치가 있는 두 개의 기사가 있습니다: 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는 쓰기에 불편한 것으로 드러났습니다.그래서 우리의 모든 페이지는 쓰기도 유지하기도 어려웠습니다.출력 형식(HTML)에 한 종류의 마크업(각 괄호)을 사용하고 다른 종류의 마크업(예: <%...메타데이터의 경우 %>).XSLT의 가장 혼란스러운 점은 XML로 작성되어 있고 XML에서 XML로 변환된다는 것입니다.사람의 마음속에 3가지의 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를 처음부터 배워야 했는데 어렵지 않았습니다.이 툴의 장점은 데이터 독립적인 C++ 코드를 작성할 수 있게 해주었고, XSD와 XSLT를 사용하여 XML 문서를 검증/검증하고 변환할 수 있게 해주었습니다.데이터 형식을 변경하고, XSD 및 XSLT 문서를 Xerces 라이브러리를 사용한 C++ 코드가 아닌 변경합니다.

참고: 주 XSD는 150KB였고 XSLT의 평균 크기는 5KB IIRC였습니다.

또 다른 큰 이점은 XSD가 XSLT의 기반이 되는 사양 문서라는 점입니다.그 둘은 호흡이 잘 맞습니다.그리고 요즘 소프트웨어 개발에서는 사양이 희귀합니다.

선언적 성격 XSD와 XSLT를 배우는 데 큰 어려움을 겪지는 않았지만 다른 C/C++ 프로그래머들이 선언적 방식에 적응하는 데 큰 어려움을 겪었다는 것을 알게 되었습니다.그들이 그것을 보았을 때, 아 절차적으로 그들은 중얼거렸습니다. 이제 이해했습니다!그리고 절차서 XSLT를 작성하기 위해 (pun?) 진행했습니다!중요한 것은 XPath를 배우고 XML의 축을 이해해야 한다는 것입니다. C++를 쓸 때 예전의 C 프로그래머들이 OO을 사용하는 것에 적응하는 것을 생각나게 합니다.

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

저는 XSLT가 좋은 아이디어라고 생각했었습니다.내 말은 그것은 훌륭한 아이디어 입니다.

그것이 실패한 곳은 실행입니다.

시간이 지남에 따라 발견된 문제점은 XML의 프로그래밍 언어는 단지 나쁜 생각이라는 것입니다.그것은 모든 것을 관통할 수 없게 만듭니다.구체적으로 XSLT는 매우 어렵게 배우고, 코딩하고, 이해한다고 생각합니다.기능적인 측면 위에 XML을 사용하면 모든 것이 너무 혼란스러워집니다.제가 경력을 쌓으면서 5번 정도 배워보려고 했는데 잘 안 돼요.

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

XSLT 규격은 XSLT를 "XML 문서를 다른 XML 문서로 변환하기 위한 언어"로 정의합니다.XSLT 내에서 가장 기본적인 데이터 처리 이외의 작업을 수행하려고 한다면 아마도 더 나은 솔루션이 있을 것입니다.

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

• IMT2000 3GPP - MSDN 설명서
• Csharp Frifends자습서

저는 회사의 온라인 문서 시스템을 유지하고 있습니다.작성자는 문서를 SGML(xml like language)로 작성합니다.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 인터페이스를 사용하여 웹 앱을 작성했을 것입니다. 그리고 전통적으로 XML이 XSLT에 의해 변형되어 온 분야에서 JSON과 같은 데이터 "언어"가 설득력을 얻고 있다고 생각합니다.그러나 현재 XSLT는 여전히 중요하고 유용한 기술입니다.

XSLT에서 많은 시간을 보내면서 XSLT가 어떤 상황에서는 유용한 도구가 되기는 하지만 그렇다고 전부 해결되는 것은 아니라는 것을 알게 되었습니다.기계로 읽을 수 있는 XML 입력/출력을 위한 데이터 변환에 사용될 때 B2B 용도로 매우 잘 작동합니다.저는 당신의 한계에 대한 진술이 잘못된 것이라고 생각하지 않습니다.저를 가장 실망하게 한 것 중 하나는 XSLT의 구현에 있어서 뉘앙스였습니다.

아마도 당신은 이용 가능한 다른 마크업 언어들을 살펴봐야 할 것입니다.Jeff가 Stack Overflow와 관련된 바로 그 주제에 대해 기사를 작성했다고 생각합니다.

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

저는 그가 쓴 것을 볼 겁니다.당신은 아마도 당신이 원하는 것을 처음부터 쓰는 대신에 "즉석에서" 또는 적어도 아주 가까운 곳에서 할 수 있는 소프트웨어 패키지를 찾을 수 있을 것입니다.

저는 현재 공공 사이트에서 데이터를 스크랩하는 일을 하고 있습니다(네, 알고 있습니다).다행히도 xhtml과 호환되어 필요한 데이터를 수집할 수 있게 되었습니다.결과적인 솔루션은 읽기 쉽고, 깨끗하며, 필요한 경우 변경하기 쉽습니다.완벽해!

XSLT를 써본 적이 있습니다.6.xslt 파일 그룹(하나의 큰 파일 중에서 리팩토링)은 제가 C#로 다시 작성하기 전까지 약 2750행이었습니다.C# 코드는 현재 4000행으로 많은 논리를 포함하고 있습니다. XSLT로 쓰기 위해 무엇이 필요했을지는 생각하고 싶지도 않습니다.

제가 포기한 시점은 XPATH 2.0이 없다는 것이 저의 발전에 큰 타격을 주고 있다는 것을 깨달았을 때입니다.

3가지 질문에 답하기:

1. 저는 몇 년 전에 XSLT를 한 번 사용한 적이 있습니다.
2. 저는 XSLT가 특정 상황에서 올바른 해결책이 될 수 있다고 믿습니다.(Never say never)
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 파일)을 보여주고 싶을 수도 있지만 모든 사람을 위한 것은 아닙니다.

아마 당신은 당신의 저자들에게 간단한 위키나 마크다운 인터페이스를 제공하고 싶을 것입니다.이를 위한 라이브러리도 있습니다. XSLT가 사용자에게 적합하지 않다면 XML이 사용자에게 적합하지 않을 수도 있습니다.

XSLT는 xml 변환의 전부가 아닙니다.그러나 문제를 해결하는 것이 최선의 방법이었는지 또는 보다 효율적이고 유지 관리 가능한 다른 접근 방식이 있는지 여부를 제공된 정보를 바탕으로 판단하기는 매우 어렵습니다.저자들이 단순화된 형식으로 자신의 내용을 입력할 수 있다고 했습니까? - 어떤 형식입니까?문자함?어떤 종류의 html로 변환하고 계셨나요?XSLT가 해당 업무에 적합한 도구인지 판단하려면 이러한 변화의 특징을 보다 자세히 파악하는 것이 도움이 될 것입니다.

저는 XML 문서의 트리 구조 변경에만 XSLT를 사용하는 것을 즐깁니다.XSLT를 XML 문서에 적용하기 전이나 후에 실행할 수 있는 사용자 정의 스크립트로 텍스트 처리와 관련된 작업을 수행하는 것이 번거롭습니다.

XSLT 2.0에는 훨씬 더 많은 문자열 기능이 포함되어 있지만 언어에 적합하지 않다고 생각하고 XSLT 2.0의 구현이 많지 않습니다.

언급URL : https://stackoverflow.com/questions/78716/is-xslt-worth-it