한빛출판네트워크

제공 : 한빛 네트워크
저자 : Eric Larson
역자 : 오윤재
원문 : Where are the XML Editors?

최근 나는 업무 가운데 하나로, 완전히 처음부터 우리가 만든 언어들 세트를 가지고 작업을 할 수 있는 시간을 가졌다. lexer(단어 단위로 자르는 것)와 parser(lexer로 자른 단어들의 의미를 분석하는 것)의 관점에서 생각한다는 것은 흥미로운 일이지만, 나의 궁극적인 목적은 XML과 XSLT를 적당한 어딘가 사용하고픈 바람이었다. tree 형태는 강력하다. 특별히 그 tree 내에서의 재귀적인 작업에 초점을 맞춘 언어를 사용할때 더욱 그렇다.

완전히 처음부터 parser를 작성한 이유는 전적으로 사용 편의성를 위해서 였다. 실제 그 언어를 사용해야 하는 사람들은 더욱 유연하고 간략화된 텍스트 포맷으로 이용이 가능하기에 그렇게 만들었다. 이런 것을 프로그램으로 짜는 일을 더 힘들지만, 실제 사용자들을 그 덕을 톡톡히 본다. 그렇기에 추가적인 작업이긴 하지만 그건 가치가 있었다.

처음에 XML이 고려되었다고 들었다. 하지만, 작업을 쉽게 하기 위해 에디터를 사용하지 않았는데, 그것은 현실적이지 못했다. 괜찮은 에디터가 부족한 점이 장애물이었다는 것은 흥미롭다. 내가 알기로 XML이 이렇게 널리 채택되기 전에도, 열성적인 사람들은 에디터들이 이런 모든 각 괄호(< >) 사용을 없애 그러한 고통을 덜도록 도와주어야 한다고 제안했다. 내가 부정확할 수는 있다. 하지만 XML 에디터의 세계가 그리 이상적이지 않다는 사실만은 부정할 수 없다.

몇몇 진짜 뛰어난 XML 에디터들이 있다. 예를 들어, 내손이 Emacs에 길들여져있지 않고 자유로왔다면, oXygen은 내가 선택할 수 있는 에디터였을 것이다. 이것은 환상적인 XML 프로그래머들의 에디터이다. oXygen이 좋지만, 그렇다고 그것이 비기술자들을 위해 만들어진 것은 아니다. 여러 시도들은 있어 왔다. 특별히, 출판계에서는 성과가 있었다. 하지만, 비기술자들에게 적합한 일반적인(혹은 보편적인) XML 에디터는 그저 희망사항인 것 같다.

선택의 폭이 좁다는 것은 그리 놀랄만한 일은 아니다. 왜냐하면, XML의 무한한 가능성이 에디터를 만들때 걸림돌이 되는 것 같다. 에디터의 기본은 화면 이면에서 그 구성을 유지하기 위해 몇몇 제약사항을 관리해야 한다는 점이다. 이것은 보통 결국 XML 스키마 또는 업데이트를 위한 시간 소모적인 다른 몇몇 언어의 스키마와 관련된다. 한마디로, 이것은 왜 여러분이 JavaScript를 작성하기 위해 몇몇 추가적인 도구들과 함께 기능이 많은 텍스트 에디터나 워드를 사용하지 않았는지와 같은 이유이다.

XML 에디터가 생산적일 수 있는 한가지 길은 "XML by example(예제를 통한 방식)" 이다. 복잡한 스키마를 요구하는 대신, 에디터는 하나의 샘플 XML 파일을 예제로서 사용할 수 있다. 프로그래머들은 XML을 작성하는 소프트웨어를 만드는 것을 아주 잘 한다. 그래서 이것은 아주 그럴듯한 요구사항인 것 같다. XSLT 또는 더 간단한 어떤 것이든 저장 혹은 검증작업을 만들기 위해 사용될 수 있다. 여러분은 링크 뿐만 아니라 숫자나 날짜 같은 컨텐츠 타입을 검증할 수 있다. 사용자가 XML을 작성한 어떤 시스템이든 잘못된 데이터를 대비해 단방향 혹은 여러 방법으로 준비해야 한다. 모든 output 파일들을 망라해서 작성하는 것이 매우 좋다.

더 중요한 질문은 심플한 XML 에디터들이 너무 늦지나 않았는지 하는 것이다. XML에 대한 관심은 더 대중화되고 있는 JSON 같은 기술로 인해 분명히 줄어둘고 있다. 이것을 고려하더라도, XML의 강점은 특별히 전통적인 컨텐츠 관리 상황 가운데서는 여전히 가치가 있다. 전통적인 컨텐츠가 있는 곳에서 심플하고 보편적인 XML 에디터가 가장 가치를 발하게 된다는 것은 그리 놀랄만한 일이 아니다.

여러분은 어떻게 생각하는가? 실제 사용자들을 위해선 심플하고 보편적인 XML 에디터가 가치있는 도구인가? 어떨것 같은가?

추가사항!

몇몇 좋은 코멘트들이 있었다. 그래서 잠깐 시간을 내어 몇가지를 분류해 답변을 하고자 한다.

우선, 내가 "보편적인 에디터(generic editor)"라고 의미한 것은 아래 코멘트들 가운데 Evan의 설명이 훨씬 더 진짜에 가깝다. XML을 가지고 컨텐츠를 제작하는 관점에서 생각했었다. 왜냐하면, 나는 그것이 XML을 뛰어나게 하는 한 영역이라고 굳게 믿고 있기때문이다. Paul Terrey는 Arbortext, XMetaL, Serna, 기타 등등에 대해 언급하는데, 그것들은 사실 이 기사를 작성하기 위한 기폭제였다. 또한, George Bina (oXygen 소속)는 oXygen XML Author가 있다고 지적했는데, 그건 Arbortext 혹은 XMetaL의 것과 비슷한 카테고리에 속하는 것 같다.

Laurens van den Oever는 XML 저작 에디터가 유효한 결과물을 제공할 수 있도록 중점을 둬야한다고 지적한다. Evan Lenz는 또한 에디터를 만들 때 XML 스키마 (또는 DTD) 사용의 중요성을 제안한다. 전반적으론 동의한다. 하지만, 문제는 워크플로우에 기반한 XML을 이용함으로 이점을 누리는 많은 그룹들이 복잡한 에디터를 구성하기 위한 기술적인 자료들을 가지고 있지 않다. 물론, 그들은 컨설턴트를 고용할 수 있다. 하지만, 지원을 받기도 힘들고 비용이 많이 들 수 있다.

한가지 아이디어는 전통적인 비기술자들이 그들의 스키마들 변경하고 새로운 포맷을 추가할 수 있도록 할 수 있는가 이다. 이 경우, 저작 환경뿐만 아니라 스키마를 생성하는 툴이 그 해결책이다. Dimitre Novatchev는 XML파일로 부터 XSD를 추출해 내기 위해 Visual Studio를 사용하는 것을 언급한다. 그것은 하위 레벨 전략차원에서는 좋다. 하지만, 나는 뭔가 더 한발 나가 Access 처럼 하위레벨의 세부적인 사항과 사용자 편의성이라는 간격의 차이를 돕는 것을 생각해 본다. 아무리 도구들이 도움이 된다할지라도, 그 문제는 극복해야할 도전임에는 분명하다.

마지막으로, 내가 좋은 XML 저작 환경에 관심을 가지고 있는 한가지 이유는 블로깅을 위해서이다. 특별히, AtomPub 상황하에서의 블로깅을 말한다. Atom 익스텐션들을 통해 기능을 추가하고 제거하는 능력을 가진다는 것은 저작툴로서 XML에게 안성맞춤인 것 같다. 마찬가지로, 예를 들어 oXygen XML Author는 DITA 또는 XHTML 같은 것을 지원하는 Atom 프레임워크를 지원하는데, 그것은 CMS 통합을 위해 매우 뛰어나다. 이런 류의 생각은 새로운 것이 아니다. 결국 현실에 훨씬 더 접근했다는 점이다.