XSLT 및 가능한 대안 [폐쇄]

한 XML 파일을 다른 XML 파일 (HTML 등)로 변환하기 위해 XSLT를 살펴 보았습니다. XSLT (표준화되고 사용되는 도구 임)에 이점이 있다는 것을 알면서 몇 가지 이유로 꺼려합니다.

• XSLT 프로세서는 상당히 크거나 리소스가 부족한 것 같습니다
• XML은 프로그래밍에있어 나쁜 표기법이며 XSLT의 모든 것입니다.

XSLT를 트롤링하고 싶지는 않지만 대안에 대해 내가 기대하는 것에 대한 아이디어를 제공하기 위해 내가 싫어하는 것을 지적하고 싶습니다.

리스프 배경 지식이 있으면 리스프를 기반으로 트리 구조 변환을위한 더 나은 방법이 있는지 궁금합니다. DSSSL에 대한 참조를 보았습니다. 슬프게도 DSSSL에 대한 대부분의 링크가 죽었으므로 이미 그것을 보여주는 코드를 보는 것이 어렵습니다. DSSSL이 여전히 사용 중입니까? docbook 내용을 확인할 때 openjade를 한 번 설치 한 것을 기억합니다.

Jeff Atwood의 블로그 게시물 은 XSLT 대신 Ruby를 사용할 때 힌트를주는 것으로 보입니다.

비 XML 프로그래밍 언어에서 XSLT와 유사한 XML 변환을 수행 할 수있는 방법이 있습니까? 나는 입력을 위해 열려있을 것입니다

• XML 변환을 용이하게하는 스크립팅 언어에 유용한 라이브러리
• 특히 lisp와 같은 변형 언어 또는 Ruby 등 (단독은 아님)

내가 지금까지 찾은 몇 가지 :

• 웹상의 몇 곳에서 Linq가 가능한 대안으로 지적했습니다. 일반적으로 XSLT 경험이 가장 뛰어난 사람들로부터 온 모든 종류의 분류입니다.
• 체계 http://cs.brown.edu/~sk/Publications/Papers/Published/kk-sxslt/ 및 http://www.okmij.org/ftp/Scheme/xml.html

기술에 대한 깊은 경험이 없으면 기술을 평가하기가 어렵지만 물론 결정을 내려야 할 때가되므로 이러한 딜레마에 대한 간단한 답변은 없습니다.

성능과 유용성이라는 두 가지 문제를 언급했습니다. 아래에서 모두 해결하려고 노력할 것입니다.

먼저 성능. 물론 성능은 언어뿐만 아니라 구현 및 사용자의 전문성에 달려 있습니다. 다른 XSLT 프로세서는 성능이 크게 다를 수 있으며 동일한 프로세서는 사용 방법에 따라 크게 다를 수 있습니다 (예 : Saxon의 경우 성능 문제가있는 사용자는 DOM과 함께 사용하는 경우가 종종 있습니다. Saxon의 기본 트리 모델을 대신 사용하면 성능이 10 배 증가 할 수 있습니다. 따라서 첫 번째 조언은 정보에 대한 성능을 측정하지 않고 측정하는 것입니다. 두 번째 조언은 측정하는 사람이 어리석은 실수를하지 않을만큼 충분한 경험을 가지고 있는지 확인하는 것입니다. 말보다 더 쉽게 말했다.

대충, 변환 작업을 단순 및 복합의 두 범주로 분리 할 수 ​​있습니다. 간단한 변환의 경우 우수한 XSLT 프로세서를 사용하면 구문 분석 및 직렬화에 소요되는 시간이 모두 소요되며 XSLT 처리 시간은 거의 나타나지 않습니다. 다른 기술은 동일한 구문 분석 및 직렬화 비용을 발생 시키므로 변환 기술의 선택은 큰 차이를 만들지 않을 것입니다 (스트리밍을 사용하는 매우 낮은 수준의 코딩은 제외하지만 많은 사람들이 프로그래밍을 감당할 수는 없습니다) 구현하는 데 필요한 시간과 기술). 큰 문서에서 복잡한 변환을 수행하려면 SQL 프로그래밍에서와 동일한 문제가 발생하기 시작합니다. 좋은 성능을 얻으려면 프로그래머의 기술과 지식과 옵티마이 저의 기능간에 좋은 상호 작용이 필요합니다. SQL과 마찬가지로 이러한 고급 언어에서는 프로세서가 매우 많은 양의 작업을 수행해야하는 몇 가지 간단한 설명을 작성하는 것이 매우 쉽습니다. 또한 SQL과 마찬가지로 자신이하는 일을 아는 프로그래머는 초보자보다 훨씬 더 잘할 것입니다.

둘째, 유용성. XSLT의 XML 기반 구문은 언어를 처음 접했을 때 많은 사람들에게 큰 영향을 미칩니다. 그러나 이런 식으로 그렇게하는 데는 타당한 이유와 실질적인 이점이 있습니다. "템플릿"이라는 주장이 있습니다. 많은 코드가 결과 문서에 기록 될 XML로 구성되어 있으며 XML을 작성하는 가장 좋은 방법은 XML입니다. 그리고 "반사"논증이 있습니다. 복잡한 대규모 시스템에서는 스타일 시트를 생성하는 스타일 시트를 찾는 것이 매우 일반적입니다. 그런 다음 "tools"인수가 있습니다. XML 상점에 있다면 구문 지향 편집기와 같은 많은 XML 도구가있을 수 있으며 동일한 도구를 사용하여 프로그램과 데이터를 처리하는 것이 좋습니다. 단점은 비교할 때 상당히 장식적인 것으로 판명되었습니다. ■ 편집과 관련된 키 입력 횟수 (좋은 편집 도구로 쉽게 수정 됨) 및 코드의 자세한 내용 (가독성 감소)이 있습니다. XSLT 2.0에서는 정규 표현식 및 스타일 시트 함수와 같은 기능이 도입되어 자세한 내용이 크게 줄어 듭니다. 많은 스타일 시트는 XSLT 2.0을 최대한 활용할 때 크기가 절반 또는 1/3로 줄어 듭니다.

DSSSL에 대한 당신의 언급은 나를 웃게합니다. 필자는 DSSSL을 사용한 적이 없지만 그 구문이 비열하고 데이터의 구문 (SGML)과 관련이 없기 때문에 성공하지 못했다는 이야기를 들었습니다. XSLT에 대한 XML 구문의 사용은 DSSSL에 대한 경험에 의해 동기 부여되었습니다.

XSLT를 좋아하는 사람들이 있고 그것을 싫어하는 사람들이 있습니다. 당연히, 그것을 많이 사용하는 사람들은 첫 번째 범주에 빠지는 경향이 있습니다. 그것을 싫어하는 사람들은 일반적으로 "XSLT 방식을 생각하는 법"을 배우지 않은 사람들입니다. 프로그래밍 언어는 생각하는 방식에 영향을 미치지 않아야한다고 주장 할 수 있지만 규칙 기반 언어로 작성하는 것은 명령형 언어로 작성하는 것과 다른 사고 방식을 취합니다. 많은 프로그래머의 첫 번째 반응은 통제력이 떨어 졌다는 것입니다 (컴퓨터에 단계별로 수행 할 작업을 지시하는 대신 문제를 설명 함). 사람들이 SQL을 처음 소개했을 때 보았던 반응과 매우 유사합니다. 요즘 사람들은 경력 초기에 SQL을 배우므로 정신 재조정이 덜 필요합니다.

궁극적으로, 당신은 사랑 / 증오 반응이 아닌 객관적인 측정 가능한 기준에 근거한 기술을 선택해야합니다. 측정하기가 어렵습니다. 그러나 XSLT를 매우 집중적이고 성공적으로 사용하는 사람들이 많이 있으므로 그렇게 할 수 있다는 것은 의심 할 여지가 없습니다.

상황에 대한 추가 정보가 없으면 대답하기가 어렵습니다.

여전히 XSLT를 사용하지 않으려는 이유를 이해하지 못합니다. 작업에 적합한 도구이며 강력한 도구입니다. 한 XML을 다른 XML로 변환하기 위해 특별히 수행됩니다.

XSLT 프로세서는 상당히 크거나 리소스가 부족한 것 같습니다

이를 뒷받침 할 하드 데이터가 있습니까? XSLT를 사용하여 솔루션을 구현하고 XSLT 가 병목 현상을 발견 하여 성능과 관련된 모든 비 기능적 요구 사항을 충족하면서 제품을 제공 할 수 없게 되었습니까?

통계 데이터와 프로파일 링이 없으면 주어진 솔루션이 작동하지 않는다고 합리적으로 주장 할 수 없습니다. 비 기능적 요구 사항이 충분히 합리적인가? 예를 들어 XSLT를 다른 대안으로 대체하여 수백 밀리 초를 얻기 위해 10 일 동안 개발자의 작업을 낭비하고 싶습니까? 그만한 가치가 있습니까?

XML은 프로그래밍에있어 나쁜 표기법이며 XSLT의 모든 것입니다.

한 XML을 다른 XML로 변환하고 싶지만 "XML은 잘못된 표기법"이기 때문에 XSLT를 사용하고 싶지 않습니까?

XML을 너무 귀찮게하는 일종의 프로그래밍 언어로 XML을 사용한다는 사실은 프로그래밍이 아니라 많은 변환 규칙을 참조하십시오.

XSLT를 직접 작성하지 않아도됩니다. 하나의 XML을 다른 그래픽으로 매핑 할 수있는 ETL 편집기가 많이 있습니다. 프로그래밍이 필요하지 않습니다. 일부는 XSLT를 출력으로 사용합니다.

XSLT를 사용하여 원시 XSLT와 XSLT 엔진에 전달하는 일부 매개 변수를 기반으로 XML을 생성하는 경우 템플릿 XML 방식을 사용하면 이해하고 유지하기가 훨씬 쉽습니다.

나는 콧수염 이 XSLT를 대체하는 데 사용 된 프로젝트에 있었고 결과는 완전히 침묵하는 한두 명의 용감한 영혼에게 프로젝트 작업을 전달하는 대신 모든 사람이 편집하고 조정할 수있는 훨씬 간단한 기본 XML 파일이었습니다. 땀이 쏟아져 나오는 ...

기본 XML이 자체적으로 유효한 데이터이고 XSLT를 사용하여 대체 표현을 제공하거나 소스 XML에서 추출한 경우 템플릿 접근 방식을 사용하기에 적합하지 않습니다.

XML은 프로그래밍 언어가 아니다

XML은 데이터를 전송 / 전송하는 방법입니다.
XSLT 명령어는 Xpath를 사용하여 특정 방식으로 데이터를 쿼리하여 다른 데이터 전송 개체 / 문서에 넣는 것입니다.

그리고 / 또는

XSLT는 XML을 HTML로 변환 할 수 있는데, 이는 XML 문서에 포함 된 데이터를 표시 / 전송하는 또 다른 방법입니다.

XML을 변경하거나 XML 문서를 만들려는 경우 C #, VB, Ruby 등의 여러 언어를 사용할 수 있습니다.

일반적으로 XSLT 파일을 사용하여 XML 문서를 변환 할 때 여전히 원본 XML 문서가 있으며 실제로 원본 문서를 변경하지 않고 실제로 새 문서를 만듭니다.

XSLT 라이브러리가 좋지 않은 부분에 대해 XSLT 라이브러리를 Java 또는 C ++와 결합하는 여러 XML 처리 시스템에서 작업했습니다. 20MB XML 파일에서도 XSLT 성능이 매우 우수한 라이브러리가 있지만 XSLT에는 컨텍스트, 변수 및 복잡한 문자열 패턴에 대한 제한이 있습니다. 내가 작업 한 각 시스템은 컨텍스트가 중요하거나 복잡한 정규 표현식이 도움이 되었기 때문에 Java / C ++에서 몇 가지 작업을 수행했습니다. XSLT와 선택한 언어로 된 추가 코드가 XML을 변환하는 좋은 방법입니다.