2014년 7월 29일 화요일

OOXML, OWPML 모두 공공문서 포맷으로 부적절

'전자문서 산업을 위한 학술 토론회' 관련 기사:

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140725153903

OOXML은 ISO/IEC 29500 표준으로 MS 오피스의 포맷이고 (docx, pptx 등), OWPML은 KS X 6101 표준으로 한컴오피스2014부터 hwpx라는 이름으로 (아직은 시험적인) 포함된 포맷이다.

이 학술 토론회에서는 업체 사람들이 서로 자기 업체의 포맷을 가지고 자기 포맷이 더 개방적이고 표준으로 바람직한 공공문서 포맷이라고 주장하고 있으나, 사실 OOXML이든 OWPML이든 공공 문서 포맷이 되기에는 마찬가지 문제를 가지고 있다.

OOXML


OOXML의 문제는 이미 과거 표준화 과정에서부터 충분히 알려진 바 있다.

마이크로소프트 측은 6000 페이지의 문서로 구성된 표준을 급행으로 검토할 시간도 주어지지 않은 채 진행하면서, 그 전에 기존에 표준 결정 기구에 가입하지 않은 개발도상국가에 입회비를 지원한 스캔들이 있었다. 이들 개발도상국가가 표준안에 찬성표를 던진 것은 물론이다. (대한민국은 최종적으로 반대에 투표했다.)

http://www.zdnet.co.kr/column/column_view.asp?artice_id=00000039161482

기술적으로도 알려진 것만 해도 그렇다. OOXML은 기존의 바이너리 오피스 포맷을 가지고 XML을 컨테이너로 이용한 것 뿐이다. 이러면 XML 파서로 읽을 수 있을 뿐 기존 오피스 포맷과 다를 게 없다. 대표적인 예로 드는 useWord97LineBreaks attribute는 "Word97방식으로 렌더링하라"라고 지정되어 있고 그 Word97 방식이 무엇인지 설명하지 않는다.

http://msdn.microsoft.com/en-us/library/documentformat.openxml.wordprocessing.useword97linebreakrules%28v=office.14%29.aspx

OOXML은 마이크로소프트 사의 역사적인 이진 형식을 주의 깊게, 하나도 빠뜨림 없이, 꼼꼼하게 XML 형식으로 복사한 결과물일 뿐이다.

XML 은 새 문서 형식을 정의하는 강력하고 풍부한 도구지만, 프로젝트 범위를 잘못 정하는 실수까지 무마해 주는 만병통치약은 아니다. '참고할 문서가 없는 대형 독점 렌더링 라이브러리를 사용한다'는 플래그를 문서 형식에 넣는다면, 플래그를 문서 없는 이진 문자열 내 비트 하나로 명세하든 세 쪽짜리 <>으로 명세하든 상관이 없다. 이 명세는 어디까지나 독점이며, 단순히 XML로 감싸는 방법만으로는 렌더링이 불가능하다.

IBM Developer Works, "OOXML 무엇이 그리 대단한가 " 중에서, http://moonistar.tistory.com/m/post/16


OWPML

이 글을 쓰기 시작한 이유가 바로 이 포맷 때문이다. 올해 초에 직접 KS X 6101 표준 문서를 구입해서 한컴오피스 2014 체험판의 HWPX 결과물과 같이 검토해 봤기 때문이다.

바이너리 MS 오피스 포맷을 XML로 옮긴 게 OOXML이라면, 바이너리 HWP 포맷을 XML로 옮긴 게 바로 OWPML이다. 이것 뿐이다. XML의 파일 하나하나는 HWP에 있던 Compound Document의 스트림 하나하나에 대응하고, XML 태그 하나하나는 HWP에 있던 레코드 정보에 대응하고, XML 속성(attribute)은 레코드의 바이너리 데이터에 해당한다. IP over XML 같은 만우절 장난이라면 몰라도, 이런 포맷을 만드는 게 무슨 의미가 있는 걸까?

KS X 6101 역시 OOXML 포맷과 같은 오류를 저지르고 있다. 무엇무엇이 있다라는 설명만 하고 실제 어떻게 구현되는지 제대로 설명하지 않아 사실상 한글과컴퓨터의 구현만이 알 수 있게 되어 있다. 예를 들어 표준 7.1에 보면 XMLTemplate/ 이라는 폴더에 대해 언급했으면서 표준 문서 다른 어디에도 여기에 대한 설명이 없다.

또 한 가지 예를 들면 표준 문서 "8.2.4 호환성 정보"를 보면 "compatibleDocument" 태그가 있다.
<compatibleDocument  targetProgram="MS_WORD">...
이런 식으로 쓰면 붙이면 MS-Word 방식으로 렌더링한다. 앞의 OOXML에 있던 useWord97LineBreaks 속성이 생각나는 부분이다. 이 MS-Word 방식이 무엇인지는 알 길이 없다. 원래 HWP 포맷에도 마찬가지의 호환성 문서 정보가 있는데 이 정보까지 OWPML에 그대로 구현해 놓은 것이다. 한컴오피스에서 MS-Word 문서가 상당히 잘 변환되는 비밀이 여기 있다. HWP 포맷에 MS-Word 호환 모드가 있고 한컴오피스에 MS-Word와 비슷한 렌더링 방식을 구현해 놓은 것이다. 이런 것까지 표준에 포함하면 표준 구현은 한컴오피스가 한 것처럼 MS-Word 렌더링 방식까지 따라해야 한단 말인가?

이런 문제점을 지적해야 할 표준 심의 과정도 문제였다. KS X 6101:2011 문서의 해설에 기록되어 있는 표준 제정 과정의 7가지 심의 의견 중에서 문제를 지적한 의견이 6가지인데, (1) 표준 제목 수정 (2) 오타 수정 (3) HWP 약자 설명 추가 (4) ODF, OOXML 상호운용성 추가 (5) ODF, OOXML 인용 추가 (6) 수식, 화학식 누락. 이 중에서 (1)(2)(3)(5)은 단순 수정이고, (4)는 이 표준에서 해당하지 않는다고 조치했고, (6)에서 수식이 추가 된 게 그나마 유일하게 의미 있는 문제점 수정 사항이었다. 한글과컴퓨터에서도 최근 한컴오피스2014에서 처음 구현했으니 검증될 기회도 없었다.

OOXML과 마찬가지로 똑같은 포맷을 XML로 감싼다고 해서 구현할 수 있는 건 아니다. 검토했던 결과를 다음 페이지에 기록해 놓았다.

https://docs.google.com/spreadsheet/ccc?key=0AjxIVzS0OjQTdEc5V1dhLWJwenhSTEpPWGNMdy12NUE&usp=sharing

기록한 것과 같이 OWPML은 표준에도 오류가 있는데, 이 포맷을 최초로 구현한 한컴오피스 2014의 HWPX 포맷에서도 표준에 없거나 표준과 다르게 사용하고 있다.

ODF 뿐이다


아무리 OOXML과 OWPML이 표준으로 인정받았더라도, 의도적이든 아니든 사실상 특정 업체 독점적이 될 수밖에 없도록 기술된 포맷은 공공문서의 포맷이 되면 안 된다. 현재 나와 있는 해법은 ODF 뿐이다. ODF는 다들 좋아하는 그 표준을 국제/국내 모두 오래전에 획득했다.

물론 같은 학술 대회에서 다음과 같이 한컴 측이 주장한 것과 같이 ODF도 구현별로 차이가 나는 것도 사실이다.
또 국제표준이 만능이 아니라고 반박했다. 그는 “MS 오피스도 환경에 따라 레이아웃이 깨지는 경우가 많고, ODF도 오픈오피스, 심포니, MS 오피스 등 구현회사마다 조금씩 차이가 있다”고 말했다.
http://www.ddaily.co.kr/news/article.html?no=120789
하지만 구현 과정에서 조금 차이가 난 것과, 아예 기본적인 명세부터가 제대로 독립적으로 구현하기 힘든 것과는 천지 차이이다. (게다가 오픈오피스는 오픈소스이고, 심포니는 오픈오피스 기반으로 개발된 것이다. MS 오피스의 ODF 지원 기능은 외부에서 만든 플러그인이 더 낫다고 할 정도로 완성도가 낮아서 생긴 일이다.  http://en.wikipedia.org/wiki/OpenDocument_software#Microsoft_Office_2007_SP2_support_controversy )

ODF를 사용하도록 규칙을 제정하고, 공공에서 사용하는 한컴오피스에 대해 기본 포맷을 ODF로 저장하도록 하는 게 처음 한 걸음이 될 것이다. 문제가 되는 HWP 문서 생산을 멈춘 다음 과거 HWP 문서의 변환도 고민하자.

댓글 2개:

  1. OOXML 의 word97 관련 링크 ( http://msdn.microsoft.com/en-us/library/documentformat.openxml.wordprocessing.useword97linebreakrules%28v=office.14%29.aspx )에 가보니 지금은 단순히 word97 방식으로 그리라는 설명 외에도 추가적인 설명이 덧붙어 있네요. 공개된지 한참 되어서 요즘은 많이 개선된걸까요? 요즘 보면 3rd-party 업체들의 오피스 문서 지원 수준(적어도 view 측면에서는)이 상당하다는 느낌을 받을 때도 많고요.

    답글삭제
    답글
    1. 저건 라이브러리 레퍼런스니 한참 뒤에 쓰여진 거고, 표준엔 그런거 없어요. 애초에 표준에 MS 레가시를 지원하는 걸 넣을 이유가 없죠.

      삭제

뜬금없이 문법 따위를 지적하거나, 오래된 글에 링크가 깨진 걸 지적하는 등의 의미 없는 댓글은 자제해 주시기 바랍니다. 그러한 경우 답 없이 삭제합니다. 또한 이해 당사자이신 경우 숨어서 옹호하지 마시고 당사자임을 밝히시길 바랍니다.

참고: 블로그의 회원만 댓글을 작성할 수 있습니다.