MoniWiki XML/XSL

모니위키는 최초 1-pass xhtml 포매팅 엔진으로 시작해서 CVS 버전에는 3-pass xhtml 포매팅 엔진이
내장되어 있다. 두가지중 한가지 엔진을 기본 엔진으로 쓸 수 있다.

그러나, xhtml로 변환되면 원래 위키문법이 가지고 있는 의미 요소들의 상당부분이 희석되기때문에 이것을 원래의 위키문법으로 변환하는 것이 쉽지가 않았고, (WikiWyg는 내장된 간단한 xhtml <=> 위키문법 변환기가 들어있다.) wiki <=> xhtml,pdf 등등의 변환에 중복된 투자가 필요하게 되었다.

이러한 문제점을 줄이기 위해서 모니위키용 XML/XSL 포매팅 엔진의 필요성이 대두되며, XML/XSL을 통해서
좀 더 쉬운 포맷간의 변환이 가능해 질 것이다. 그리하여 모니위키는 1-pass / 3-pass xhtml 엔진과 더불어 제 3의 포매팅 엔진을 가지게 된다.
== MoniWiki XML/XSL ==
이미 이러한 시도는 모니위키의 개발자 advanced님에 의해 모니위키 초창기 개발때부터 제안되어졌다.
이를 정리하고, MoniWiki + WikiWyg + docbook XML의 교집합, 위키 <=> XML간의 변환에 핵심적인 의미요소로 구성된 MoniWiki용 XML/XSL을 만든다.
=== dynamic 콘텐츠와 static 콘텐츠의 분리 ===
모니위키를 비롯한 많은 위키엔진은 플러그인/프로세서를 지원한다. 각각의 플러그인과 프로세서는 그 랜더링 결과물이 항상 고정적일 수도 있고 변화할 수 도 있다. {{{[[RecentChanges]]}}}를 비롯해서 대다수의 매크로 플러그인은 dynamic 매크로이다. 랜더링 결과가 수시로 변할 수 있으므로 캐싱할 때 주의해야 한다.
반면 몇몇 플러그인과 프로세서는 static하다. 한변 변환된 랜더링 결과는 절대로 다른 모양으로 변하지 않는다.

이와 비슷하게, 대부분의 위키엔진에서 지원하는 WikiName CamelCase 혹은 {{{[[위키이름]]}}}과 같은 링크요소는 그 랜더링 결과물이 변한다. 페이지가 없으면 물음표가 붙으면서 링크가 걸리고, 페이지가 있으면 링크가 제대로 걸리게 된다. 따라서 이 부분도 xhtml 캐싱에 고려해야 한다.

기존 3-pass xhtml MoniWiki 포매터는 다음과 같은 변환 단계를 거친다.
 1. 2-pass 위키 블럭 파서
 1. xhtml 파서(WikiName 프로세서 플러그인 처리. 부분적인 캐싱)
 1. xhtml 결과물
  1. dynamic 매크로만 선택적으로 처리하여 캐싱에 반영.
----
MoniWiki XML/XSL 포매터는 다음과 같은 변환 단계를 거친다.
 1. 2-pass 위키 블럭 파서
 1. xml 파서 (WikiName, 프로세서, 플러그인, 스마일리 미처리. 완전한 캐싱 가능)
  1. xml {->} xhtml/pdf/latex/docbook 변환. 각 프로세서, 매크로별 캐싱.

여기서 살펴보면, 두번째 단계에서 프로세서/매크로를 처리하지 않고 완전한 캐싱이 가능하다. 이는 기존의 1-pass, 3-pass 포매팅 엔진보다 빨라질 수 있다는 것을 의미한다.

----
 * InterWiki처리: InterWiki는 실질적으로 정적 콘텐츠이다. 그런데 이것을 변환하는 과정에서 인터위키맵 + 인터위키 아이콘을 참조하게 된다. 인터위키맵 + 인터위키 아이콘 맵이 바뀌면 그 내용도 바뀔 수 있다.
  * 그럼에도 불구하고 고정 콘텐츠로 처리하는 것이 낫다. 인터위키맵 + 인터위키 아이콘은 거의 변화가 없는 내용이다. 고정된 내용으로 생각한다.
 * 페이지 이름: 위키위키에서 페이지 이름의 링크를 생성하기 위해서는 전통적으로 그 페이지가 있는지 없는지에 대한 판별을 한다. 위키페이지는 아주 빈번한 것은 아니지만 생성/삭제 및 링크 이름이 바뀌는 등의 변화가 빈번한 편이다. 동적 처리를 하는 것이 바람직할 것이다.
 * 매크로/프로세서: 많은 경우가 동적인 컨텐츠다. 그러나 정적 컨텐츠도 있다. vim과 같은 프로세서는 한번 랜더링 된 결과물이 바뀌는 경우는 없다. {{{Date}}}매크로 같은 경우는 정적인 컨텐츠다. 매크로가 정적인 경우에 대해서는 매크로 내에 정보가 있어야 할 것이다. 동적/정적인 매크로/프로세서에 대한 정보는 처음 한번 읽어들인 후에 캐싱하면 될 것이다.
 * 스마일리: 정적인 콘텐츠로 보는 편이 낫다. 그러나 사용자별로 다른 스마일리를 사용할 수 있게 한다면 동적 콘텐츠로 생각해야 한다.
== 해야 할 일 및 주의사항 ==
 1. xml {->} xhtml/pdf 변환에서 xslt엔진으로 가능한 부분이 있고 불가능한 부분이 있다.
 1. static/dynamic 플러그인/프로세서의 분리. (1.1.4부터)
 1. 위키 문법의 보존. wiki {<->} xml 양방향 변환기를 우선적으로 만든다. 이미 WikiWyg는 프로세서와 매크로에 대해서 중복된 처리를 하고 있다. 그렇게 되면 WikiWyg에서 할 일이 대폭 줄어들 게 된다. <!> <!> (./)
== 메모 ==
 1. php 4.x에서 지원하던 XSLT expat엔진 대신에 php5.x에서는 새로운 XSL엔진으로 대체되었다. 많은 호스팅 업체에서 지원하지 않을 가능성이 높다.
