{{{
 {{{#!html
<font 어쩌고.. >글자</font>
 } } }
}}}

라고 쓰면 html을 삽입할 수 있고,
{{{
 {{{#!gnuplot
plot sin()
 } } }
}}}
하면 gnuplot그림도 들어가게 되지요.

이것으로 {{{ }}}문법의 확장을 하면 되는 것이기 때문에 범용 블럭 등등의 새로운 괄호문법 확장이 불필요합니다. 기타 버전 관리 문법등등 기존 모인모인 문법에 새로운 문법을 첨가하는 형태는 없을것이며, 매크로나 프로세서를 활용할 것입니다.
--WkPark
|}}

이 문제 한 번 더 고려해 주세요. 권순선님 의견도 필요할 것 같습니다. KLDP 위키가 거론되던 초기에 비해 권순선님이 DocBook에 두는 무게가 줄긴 했습니다만 이 정도까지는 아닐 거라고 생각합니다. 

우선, DocBook에 대한 문제는 일반적인 의사소통을 위한 것은 아니고 "리눅스 한글 문서"라고 불릴만한 문서를 작성할 때에만 적용되는 것이므로, 새로운 문법들을 추가한다고 해도 일반적인 사용에 불편을 주게 되지는 않을 것입니다. DbWiki를 보시면 알겠지만 그냥 서로 이야기하는 곳에서는 아주 간단한 문법들만 사용합니다...

본론으로 들어가서, 제가 걱정하는 것이 무엇인지에 대한 한 가지 예를 들죠. DocBook에는 참고나 주의 등을 위한 <note>라는 요소가 있습니다. 만일 <note>를 표현하기 위해 <note>, <title>과 기타 여러 DocBook 태그들을 사용해야 한다면, 예를 들어 이런 식으로 해야 한다면
{{{
 {{{#!docbook
<note><title>참고</title>
<para>어쩌구 저쩌구 <ulink url=" .. " ...
<emphasis>블라블라</emphasis>
..
</note>
 } } }
}}}

아마 <note>를 사용하지 않는 사람들이 더 많을 것입니다. 아마 외관상 비슷한 { { |를 사용할지도 모르겠네요. 그렇다고 { { |를 note에 할당한다고 해도 비슷한 용도의 <info>, <warning> 등은 처리가 안 되구요.
 MoniWiki의 FootNote매크로를 써서 해결 할 수 있다고 봅니다.

새로운 문법을 추가하지 않고 편하게 표현할 수 있는 것은 section, para, ordered/itemizedlist, ulink, table 등 HTML의 비슷한 요소들과 대응되는 것들 뿐입니다. 

가장 걱정되는 것은, 사람들이 DocBook은 별로 신경쓰지 않고 그냥 HTML로 원하는 모습이 나타나는 것으로 만족하게 되는 것입니다. 권순선님이 KLDP.net 게시판에 위키에 대한 공지를 썼을 때부터 계속 걱정하던 문제가 바로 이것입니다. DocBook이 더 이상 KLDP의 표준 문서 형식이 아니라면 차라리 속이 편하겠습니다. 혹시 KLDP가 DocBook을 채택했을 때 충분한 논의가 없었다면(가부를 결정하는 논의뿐만 아니라 DocBook을 채택한다는 것이 어떤 의미이고 이후 어떤 영향을 미칠 것인가 등등에 이르는), 지금이라도 다시 논의를 하는게  어떨까요.

--류광

KLDP에서 DocBook을 채택한 가장 큰 이유는 하나의 소스로부터 html, ps 등등.... 다양한 형태의 출력물을 얻어낼 수 있다는 것이었지. 태그가 의미를 갖는 DocBook의 특성은 사실 제대로 활용이 되지 못했고, 각 태그별로 지니는 의미를 정확하게 가려서 쓰는 사람도 많지 않았으며 그나마도 참여하는 인원수가 점점 줄어들고 있었지요. 위키 채택으로 인해 기대되는 효과 역시 그러한 점은 고려하지 않았습니다. 그렇지만 지금까지 KLDP에 참여한 사람들의 DocBook 사용 형태를 보면 사용하는 태그의 종류도 그다지 많지 않았고, 말씀하신 것과 같은 특징을 제대로 활용하는 이도 거의 드물었습니다. DocBook을 출력물 위주로 사용하겠다는 것 때문에 DocBook 자체의 활용 방안과 그 영향까지 원점에서 재검토해야 한다는 말은 수긍하기가 조금 어렵네요. 그 이야기는 마치 이왕에 DocBook을 사용하려면 제대로 사용하고, 그렇지 않으면 아예 사용하지 말라는 말씀처럼 들리는데 현실적으로는 쉽지가 않습니다. -- [권순선]

좀 조급한 마음으로 썼는데, 아예 사용하지 말라는 말은 아니었습니다(그런 말을 할 자격도 없구요 ^^). 

다만 DocBook 지원 강화는 WkPark 님이 조금만 더 관심을 가져주시면 DocBook의 적극적인 사용을 장려하면서도 기존 문법, 용법과 충돌하거나 사용자들을 혼란하게 만들지 않는 방법을 생각보다 쉽게 찾을 수 있을 거라고 믿습니다. 필요하다면 제가 DocBook 지원을 위한 보조 개발자로 MoniWiki 프로젝트에 참여할 수도 있겠구요.

그나저나 위키가 DocBook을 압박하게 될 줄은 꿈에도 몰랐습니다. 기존 DocBook 사용이 기초적인 수준에 머물러 있었던 것은 여러 가지 이유가 있었겠지만 가장 큰 것은 텍스트 편집기에서 이러저러한 태그들을 일일이 입력하는 게 번거로왔고 그래서 기존 문서의 영문만 골라서 번역하거나 예전에 권순선님이 제시하신 틀 문서를 활용하는 정도로 머물렀기 때문일 것입니다. 위키가 조금만 도와주면 그보다 훨씬 나아질 것입니다. 잘만 하면 두마리 토끼를 모두 잡을 수 있지 않을까요.

--류광

위키텍스트 문법은 애초에 DocBook 태그가 가지고 있는 특성과는 출발선이 틀리고, MoniWiki는 DocBook을 일종의 확장 개념으로 처리하고 있기 때문에 위키문법 자체를 수정하게 될 경우 프로그램의 근본적인 성격까지 변화하게 되므로 프로그램의 일관성 측면에서는 문법은 그대로 두고 { { { 을 사용한 확장이나 매크로 등으로 처리하는 것이 맞다고 봅니다. 그리고 그렇게 할 경우 아무래도 불편할 테니 그렇게까지 해서 세세한 태그들을 사용하는 사람은 많지 않겠지요. 그러나 만약 DocBook의 특정 태그들 (예를 들면 <note>)을 위키문법 자체의 확장/수정을 통해 지원하게 되었다고 합시다. 그러면 그 문법을 사용하는 사람이 많을까요? 아마 그렇지 않을 것입니다. 아무리 설명서를 잘 쓰고 안내를 잘 해도 처음 시작하는 사람들이 그런 기능들을 받아들이고 이해하는 것에는 한계가 있습니다. 그러므로 제대로 이해한 사람이면 { { { 이나 매크로를 사용하는 것이 불편하다고 해도 알아서 잘 쓸 것이고 대부분의 사람들은 그냥 지금처럼 장/절 정도만 구분하는 기능으로도 만족하고 사용할 것입니다. 출력물 기준으로 봤을때도 그정도면 충분하고요.

저 역시 DocBook의 중요한 특징중의 하나인 다양한 태그들을 사람들이 잘 활용해서 좋은 문서를 작성하기를 바랍니다만, 현재로서는 그런 특징이 DocBook을 사용하기 위해 넘어야 할 일종의 진입장벽 중의 하나로 작용하고 있으므로 이 시점에서 위키문법이 확장/변화되는 것은 프로그램의 일관성 측면이나 실제 활용도 면에서도 큰 소득을 기대하기는 어려울 것이라고 생각하고 있습니다. -- [권순선] 
----
예 알겠습니다. 마지막으로 세 가지만 이야기할께요. 

우선 호환성 또는 변화에 대해서요. 기존 문법을 바꾸자는 것이 아니라 확장된 문법을 가지자는 것입니다. 예를 들어 tar 새 버전에 새로운 옵션들이 더 추가되었다고 해도, 기존 옵션의 의미가 바뀌지 않는 한 tar를 사용하는 기존 스크립트들은 그대로 사용할 수 있잖아요. 그런 걸 이야기하는 겁니다. 간단히 말하면 하위 호환성을 보장하면서 문법을 확장하는 방법을 찾아보자는 것입니다. 완전한 상호 호환성은 이 이곳의 페이지를 그대로 퍼다가 다른 위키에 옮기는 경우에만 문제가 되는데, 그런 일은 시스터위키나 인터위키가 있으므로 불필요하구요. 이 페이지의 논의는 기본적으로 MoniWiki라는 위키 엔진이 아니라 KLDP 위키에 대한 것이고, KLDP 위키를 위한 MoniWiki 특별판-다른 모인모인 클론들에 대해 하위 호환성을 가진-을 마련한다고 생각을 하면 안 될까요.

두 번째는, 이곳의 사용자들이 많아지면 내용을 채우는 사람들뿐만 아니라 페이지를 다듬는 데 관심을 가지는 사람들도 생길 것입니다. 내용을 채우는 사람에게는 기존 문법만 있으면 되겠지만, 다듬는 사람에게 좀 더 다양한 표현을 할 수 있는 문법이 필요할 것입니다. 사실 저도, 리눅스에 대해서는 잘 모르니 페이지 내용에 기여를 할 수는 없겠지만, DocBook의 활용을 위해 포매팅을 다듬는 일을 하고 싶었습니다. 어쨌든 그런 사람들을 위해 뭐랄까 DocBook 확장 문법을 마련해 두면 좀 더 편하게 일할 수 있을 것이고, 더 나은 DocBook 문서들이 나올 것이고, 또한 진입장벽이라는 것을 위키의 도움으로 넘는 계기가 될 것입니다. 

세 번째는, DocBook에 대한 것인데요. 사실 위의 둘은 DocBook이 중요하다는 전제를 깔고 있는 것입니다. DocBook에 대해 이 곳에서 많은 논의가 있었으면 좋겠구요(뭘 바꾸자 말자 차원이 아닌...). DocBook에는 단지 출력물 기준으로는 드러나지 않는, 기본적으로는 XML이라는 것과 공개 표준이라는 것에서 비롯되는 수많은 장점들이 있다는 것을 이미 알고 계시겠지만 다시 한 번 강조하고 싶습니다..

이곳에서 좀 더 이야기하고 싶었지만, 이 정도로 마무리짓겠습니다. KLDP.net의 KLDP.org 프로젝트( http://kldp.net/projects/ldp/ )에서 거기서는 더 이상 문서를 접수하지 않겠다는 글도 보았구요. 권순선님의 의도를 좀 더 확실하게 알게 된 것 같습니다. 저도 위키를 무척 좋아하고, 문서화를 최대한 위키 안에서 해결하자는 것에 반대하지는 않습니다.

마지막이라고 했는데 삐져서 떠나는 것은 아니구요^^ 어쩌면 여기서 생성된 문서를 DbWiki에 가져가서 다듬는 일도 가끔 하게 될 것입니다. 특히 GCC 쪽이나 네트워킹 쪽 문서에 관심이 많습니다... DocBook으로 만들어서 다시 여기에 xml 소스 형태로 올릴 수도 있겠죠(DocBook 소스를 HTML로 렌더링하는 MoniWiki의 능력은 대단히 인상적이었습니다.. kldp_html.xsl에 비해 손색이 없는 것 같더군요). 

--류광

 kldp_html.xsl와 xsltproc을 사용합니다. xsltproc을 사용한다면 결과가 같겠지요. --WkPark


프로세서 플러그인 차원에서 지원 가능 한 것은 넣을 것입니다. 문법은 기존의 {{''''''{ }''''''}}를 활용하고, {{{##주석}}}을 활용한 트릭을 사용하면 특별한 문법의 추가 없이 모인모인과 호환성을 유지할 수 있다고 봅니다. 특별판을 만들거나 새로운 문법을 추가할 이유가 없지요. 모인모인의 문법체계가 간결하기 때문에 가능한 것입니다. --WkPark