현재 OOXML에 관한 이야기들(과 설득논리들)이 기술적인 비교보다는 이데올로기적인 이야기와 독점/IP같은 이야기에 완전 편향되어 유감스럽기는 합니다.

저역시 OOXML의 표준 통과를 지지합니다.
ODF는 정말 너무도 부족한 면이 많습니다.

요즘에 요런 이야기가 풀풀 풍겨 나오는데..
OOXML이 안된다! 라고 주장하는 쪽의 한 가지 이유가 "MS의 독점"이던데..
문서가 잘 기술되어져 있다면 -_- 아무나 그 문서 보고 하면 되는거 아닌가요? ;;;;

물론 안된다고 하는 측에서는 특허 부터 시작해서, 백만가지의 이유를 들겠지만 말입니다.

듣자하니, ooxml에는 ms종속적인 코드도 사용될 수 있다는데, 그렇게 되면 리눅스에서는 ooxml을 사용 못하게 되는 것 아닌가요? 제가 odf를 굳이 지지하는 건 아닌데, ooxml은 이런 이유로 반대합니다. 이부분은 제가 개발자가 아닌지라 잘 모를 수 있습니다만, 정확히 어떻게 돼나요?

개인적으로는 ODF를 지원하는 사람으로서, 사실 관련 개발자가 아니라 기술적인 관점은 잘 모릅니다. 다만, OpenOffice에 대한 것과 마찬가지로 아마 OOXML 을 정확히 지원하는 프로그램도 MS-Office 가 유일하게 될 것이라고 봅니다.

OOXML 에 포함된 스펙에는 MS에서 특허를 가지고 있는 것들이 포함되어있다고 하더군요. MS에서는 그 부분에 대해서 특허권을 행사하지 않겠다...라고 했지만, 그건 모르는거죠. -_-;; 이런저런 얘기를 봤을 때 ODF가 확실히 스펙이 부족한 것 같기는 합니다만, 이미 ODF가 ISO 표준으로 인정받은 상황에서 새로운 표준을 다시 추가할 필요는 없어 보입니다. 차라리 ODF를 더 상세한 스펙으로 올리는 게 훨씬 바람직한 방향이 아닐까 하는거죠.

현재로서는 OOXML이 더 나은 표준안일지 모르지만, 결국 표준이라는 것은 하나로 통일될 때 개발자들도 훨씬 편해질 것이라는 의견을 내봅니다. ^^

참고로... 전 JavaScript 개발자입니다. 통일된 표준안을 매우 필요로 하는 사람이죠. T^T (브라우저가 이제 그만 나와줬으면...)

"ODF를 지원 하려면 OpenOffice를 먼저 분석하여서 불분명한 부분의 스펙을 정확히 파악하여야 하는 말도 안되는 상황이 벌어질 수도 있지 않을까? 하는 냄새가 풀풀... (ODF는 OpenOffice를 위한 포멧이 였던가? 아닌데..) 그래서 개발자 들은.. ODF를 정확히 지원하려면 느슨하고 불분명한.. 그리고 약간 비 효율적인 파일포멧 때문에 잘 만들어 지지도 않은 OpenOffice 를 분석해 가면서.. 수 많은 삽질을 해야하는 사태가 발생하는 것이 싫었던 것입니다."
여기에 이의를 걸자면,
Openoffice.org는 소스가 이미 공개되어 있어서 Microsoft Office 분석하는 것과는 차원이 다를 거라 생각됩니다.
솔직히 Microsoft Office가 먼저 나와서 지금 같은 호환성이 있지, Openoffice.org 가 먼저 나왔다면 호환성 챙기는 데는 더 빠른 시간이 걸렸겠다는 생각도 있습니다.

그리고, 본문에 계속 의견을 달자면, ODF는 제작 과정이 "공개되어 있음" 도 한 몫을 하고요.
OOXML의 제정에 Microsoft 이외의 단체가 참여했다는 소리도 들어본 적이 없었음과 대비된다고 생각합니다.

오피스 소프트웨어의 여러가지 특징, 설마 Microsoft Office 에 특화된 기능들을 이야기하시는 거라면, 다른 오피스 소프트웨어에서는 왜 그런 특징들이 추가되지 않았을지...
과연 "능력이 없어서"였을까요?

또, ODF 의 취지도 "어떠한 오피스 프로그램에서도 사용 가능하게 하자" 였음에 빗대어보면
OOXML은 지나친 자사 편향의 코드가 포함되어 있다고 들었는데....
(Thinkfree에서 이것까지 지원하게 하느라 신경을 많이 쓰셨겠네요...수고하셨다고 하고 싶을 정도...)

명확한 건지, 단지 자세한 건지는 직접 까봐야 알겠지만...
개인적으로 OOXML의 현 움직임에는 우려를 표하고 싶습니다.

아, 하나 더...
지금 OOXML은 기존 표준안들에서 문제시되어 빠졌던 기능까지 자사 포맷의 호환을 위해 포함되었다고 하더군요...

오~ 활기찬 토론이 벌어졌군요 ^^ 축하드립니다~ ㅋㅋ

에...댓글에 댓글을 다는건 모양새가 이상해서 새로 달겠습니다. 트랙백으로 엮기엔 조금 부족하고. 아무튼...
ooxml에서 사용하는 기능을 다른 플랫폼에서 이용하기 위해서 이용하는 프로그램에는 분명 그 기능을 처리하는 코드가 필요할 겁니다. 그렇다면 이 코드를 ms에서 만든 것 만큼 똑같이 만들 수 있겠느냐는 거죠. 아니면 ms가 그 코드를 다른 플랫폼에서도 사용할 수 있게 공개할 것인지 모르겠습니다. (네, 모릅니다)
odf는, 적어도 odf를 완벽히 처리하는 오픈오피스는 소스 코드를 알기 때문에 그 코드를 똑같이 만들 수가 있습니다. 작동방식 그대로 말이죠. 누가 만들어주지 않는다면 직접 만들 수도 있습니다. ooxml은 ms에서 제공하는 코드가 없으면 의도된 대로 표현되지 않을 수도 있습니다. 어떻든 문서 표준을 도입하는 이유가 플랫폼에 상관 없이 같은 결과물을 얻기 위함일텐데 ooxml에는 플랫폼에 따라서 다른 모습이 보여질 수 있고, 이런 문제가 발생했을 때 오직 ms가 해결해 줘야만 한다는 겁니다. 물론 ms의 코드와 같은 기능을 하도록 코드를 작성할 수 있지만, 그 코드가 ooxml에 포함된 기능을 ms의 코드 만큼 적절히, 오류 없이, 의도된 대로 처리할 수 있는지는 보증이 안됩니다. odf는 플랫폼에 따라서 다른 모습이 보여질 수는 있으나, 누구나 나서서 해결할 수 있습니다.

http://www.noooxml.org/petition-ko
ooxml은 위의 링크의 내용이 사실이라면 표준이 될만한 요건이 안된다고 생각합니다. 앞서 말씀드린 것도 위 링크를 보고 생각한 것들이구요.
댓글의 마지막 부분에서, 오픈오피스가 산업 표준이 되는 것과 ms오피스의 소스가 공개되는 것 중 어느것이 사용자 힘으로 가능한지는 명확합니다. ms오피스의 소스가 공개되는 것은 사용자 힘으로 가능한 일이 아닙니다. 그렇다면 장기적 관점에서 볼 때 무엇이 사용자에게 혜택이 돌아갈지는 명확합니다.
그리고 표준이 두개가 되어야 한다면 표준을 정하는 것은 무슨 필요가 있는지, ooxml이 표준이 되면 odf는 표준이 아니게 되는건지도 모르겠구요.

몇 가지 궁금한 게 있습니다.
"이미 Thinkfree Office 는 OOXML 을 거의 정확히 지원하고 있습니다만."
이라는 말씀을 하셨는데요.

1. OOXML은 스펙이 6,000 페이지에 달하는 방대한 분량인데 그 스펙을 '거의' 정확하게 지원한다는 말씀이신지?
2. '거의'란 게 어느 정도를 말씀하시는 건지? 너무 모호합니다만? '거의' 호환된다는 말에 속아서 1%가 그렇게 많은 경우에 걸리는지 현실을 겪고 좌절했던 적이 한두 번이 아닙니다.
3. MS 오피스와 거의 똑같은 것을 만들겠다면 OOXML이 가장 좋은 방법이겠죠. 하지만 관점을 바꿔서 XML의 '다른 플랫폼 사이 정보 교환'이라는 근본을 본다면 OOXML이 가장 좋은 방법인지요? XML은 단순히 어떤 애플리케이션의 파일 스토리지를 위해서 만들어진 포맷이 아닌 것으로 알고 있는데요.
4. 기술적으로 뛰어나다는 말은 좀 조심스러워야 할 것 같습니다. 모든 걸 내 맘대로 알파부터 오메가까지 정의하겠다고 한다면 못 만들 게 뭐가 있겠습니까? 문제는 그럼으로써 심지어는 다른 이미 표준으로 지정되어 있는 사항들을 무시하는 사태까지 생긴다는 겁니다. OOXML 반대 진영의 글에서 볼 수 있는 것과 같이 10%가 XML 비표준 사항이고 이미 제정되어 있는 몇 가지 표준과도 충돌합니다. 한 회사의, 한 회사를 위해서 멋대로 만들어진 포맷과 여러 회사와 업계의 의견을 고려한 포맷을 가지고 기술적으로 뛰어나다는 말을 쓰는 건 좀 아닌 듯한데요. 내 '표준'을 위해서라면 다른 표준은 무시해도 상관 없다는 식이 과연 기술적으로 뛰어난 건가요?

오오............... 사람들의 지식 내공이 전부 다 대단해서 끼어들 틈이 없네요 ㄷㄷ

아무런 영양가도 없는 잡솔이지만, 개인적으로는 ODF가 완전한 산업적 표준으로 자리잡혀서 쓰여졌으면 좋겠습니다. 왜냐? 오픈오피스가 공짜니까요(잇힝~)

그리고 또 몇 가지를 말씀드린다면, '표준'이라는 건 기술적으로 가장 뛰어난 것을 채택하는 것이 아니지 않습니까? OOXML을 쓰고 싶으면 그냥 쓰면 그만입니다. 언제 IE가 W3C 표준 무시해서 불이익 본 거 있습니까? 문제는 우리가 '표준'이라고 말하는 것, 더구나 ISO 같은 가장 권위 있는 국제 기구의 표준이라고 말할 때에는 그 표준이 특정 업체의 이익이나 정책에 종속되지 않은, 산업 전반에 최대한 공평한 기회와 공유를 가져올 수 있는 것이어야 합니다. 표준은 사실 기술도 중요하겠지만 정책이란 면을 더 중시해야 한다고 봅니다. 기술적으로 뛰어난 것만을 따진다면, 어차피 기술은 하루가 다르게 더 뛰어난 게 나오기 때문입니다. 오늘 좋다고 그 형식을 표준으로 정해 놨다가, 내일 더 좋은 게 나오면 그때마다 표준을 추가해야 할까요? 그럼 표준이 수십 수백개가 될 거고 표준이 무의미해 질 겁니다. OOXML이 기술이 뛰어나다는 이유로 표준이 된다면, 그 뒤에 더 뛰어난 걸 들고 나오는 쪽은 또 그럴 거 아닙니까? "MS는 해 주고 왜 나는 안 해 주는데?"
ODF가 빠진 곳이 많다고 말씀하시지만, ODF는 기본적으로 알파부터 오메가까지 다 내가 지배하겠다고 만든 게 아닙니다. 어떤 부분에서 이미 정해진 표준이 있다면 ODF에서 굳이 따로 정의할 필요 없이 정해진 표준을 갖다 쓰는 거고, 업계의 이해관계가 차이가 나는 부분들이 있다면 느슨하게 남겨놓는 부분도 있다고 봅니다. 그건 기술이 떨어진다고 봐서는 안 됩니다. 정책의 문제죠.
그리고 표준이란 당장 좋은 것도 있겠지만, 앞으로 어떻게 되느냐도 중요합니다. 지금 빈 구멍 없이 단단하다고 표준을 덜커덩 정해 놨다가 나중에 가서 그 단단함이 빼도박도 못하는 경직성으로 변질되면 진짜 그때는 피보는 게 한둘이 아니니까요. 지금 ActiveX 공인 인증서 체제 때문에 골칫거리가 되고 있는 한국의 인터넷 상황이 말해주고 있지 않습니까?
표준을 단순히 지금 누구 기술이 가장 뛰어나느냐, 이것만 가지고 정했을 때에는 그 뛰어난 기술이 나중에는 두고두고 족쇄가 돼서 돌아올 수도 있다는 점도 고려해야 할 겁니다.
'표준'이라는 문제에 대해서, 개발자란 딱지가 변명거리가 된다고 생각하지는 않습니다. 개발자라고 하더라도, 표준이 무엇을 뜻하고 한번 정해진 표준이 오랜 기간에 걸쳐서 얼마나 무서운 위력을 발휘하는 건지는 알아야 하지 않을까요?

이 많은 코멘트 중에 정작 현업적인, 기술적인 이야기는 없네요. ㅉㅉ

솔직히 저는 OOXML의 출발점 자체부터 그다지 "순수하지 않다" 라는 것이 가장 큰 문제점이라고 생각합니다. 지금까지 MS의 전략 자체가 우리 것을 만들거나 도태시켜버리거나 둘 중 하나였던 것을 고려해 본다면 (특히 그 전매특허라고 할수 있는 FUD?) 시장 흐름 자체를 거스를 순 없다고 판단되니 표준 자체를 MS가 독자적으로 주무를 수 있는 포맷으로 가져가는 것이 훨씬 쉽게 먹힌다는 전략적 결정의 일환이었겠지요.

그렇다면 과연 이것이 공개 표준이라고 하더라도, 차후에 개선 과정 (implementation) 에서 MS가 아닌 다른 업체에서 제안해서 개정하는 방향으로 가자하더라도 혼자 북치고 장구치고 다 한 MS에서 거부의사를 밝힌다면 결국 빛좋은 개살구에 지나지 않을까요?

말씀하신 것처럼 가장 높은 시장 점유율을 보유하고 있는 MS에서 "배째라" 하고 독자적인 개선안 (사실 계속 공개할런지도 모르겠습니다만) 을 들고 나온다면 어느 누가 그에 따르지 않을 수 있겠습니까?

즉 이미 가질만큼 가지고 있는 선두 업체의 입장에서야 잃을 게 없는, 오히려 생색내고 실리도 챙길 수 있는 그야말로 일석 이조의 전략이 될것입니다.

결국 "공개"의 문제라기 보다는 "과연 얼마나 '공개'라는 컨텍스트가 유지될 수 있겠는가"의 문제라고 봐야겠지요. 즉, 기술적인 문제로 이 사안을 논의하는 것 보다는 어찌보면 "정치적인 문맥"에서 이해해야 하는 것이 더 올바른 방향이 아니겠는가 라고 생각합니다.

jef님의 말씀에 덧붙여서...
우리나라에 거의 준 표준에 가까울 정도로 많이 쓰이는 activeX의 경우, 좋다고 너도나도 쓰다가 윈도우 비스타 출시되면서 쓰기 어렵게 되자 우리나라 업체들은 "비스타의 보안 설정을 낮추시면, 저희 보안 프로그램이 설치됩니다"라고 말합니다. 물론 이 경우 보안 문제가 생기면 사용자가 보안 설정을 낮춘 것이니 ms는 잘못이 없지만, 우리나라 업체들은 어쨌건 ms에게 휘둘렸다는 느낌을 받을 겁니다. 이런 일이 ooxml이 표준 채택 이후에 일어나지 않으리라고 장담이 안됩니다. jef님이 말씀하신대로 ms가 배째라로 들고 나오면 이용자는 휘둘릴수밖에 없다는 거죠. 표준이니까요. 표준도 아닌 activeX에서도 저렇게 휘둘리는데 표준이면 오죽합니까. ooxml이 표준이 되면 odf는 사용자가 적어서 죽은 표준이 될 수 있습니다. 그때쯤 되면 ms싫다고 ooxml을 안쓸 수도 없게 됩니다.

전세계 당나귀 네크워크 검색..프로그램 없이 웹에서 간단히 해보세요. net2search.com

1. 이미 관공서에서 ODF 문서 사용을 강제화하는 나라들이 늘어나고 있습니다. 이런 국가들이 늘어난다면 오피스 시장에서 MS가 배째라고 해도 영향력이 예전만하지 못할 것입니다.

2. MS 오피스에서 ODF 파일을 사용할 때 레이아웃의 차이에 대해 얘기하셨는데 OOXML의 경우 씽크프리와 윈용 오피스와 맥용 오피스가 동일한 레이아웃을 보여주진 않을 것이라 생각합니다. 제가 예전에 윈용 오피스와 맥용 오피스에서 구식 오피스 파일을 열어보았을 때도 그렇지 못했습니다. ODF나 OOXML나 지민아빠님의 레이아웃 동일의 희망을 얼마나 만족시킬 수 있을지 의문이 듭니다. 만약 가능하다면 그 노력의 비용대비 효과가 얼마나 클까요?

3. 제 2의 SOAP 스펙이 될 가능성도 있을 겁니다. SOAP 라이브러리 중 SOAP 스펙을 제대로 구현한 라이브러리를 찾기는 매우 힘듭니다. 6000페이지의 스펙을 제대로 구현되길 기대하는 것은 비현실적이란 느낌이 듭니다. 씽크프리에서 얼마나 잘 구현하셨는지 모르겠지만 제대로 된 복수개의 구현이 나오는 것은 힘들 것입니다. 소수의 구현체가 나오는 표준이 얼마나 가치있을까요?

4. 법적인 문제도 생각해볼 수 있습니다. OOXML은 일부 MS의 기술과 연관이 있습니다. MS가 언제까지 그 기술을 공개한다고 보장하겠습니까?

음...그런데 ooxml은 ms오피스를 이용해서 구현시킨다든가 하는게 불가능하죠. 그럼 오픈오피스를 이용한 구현이 얼마든지 가능한 odf가 좀 더 자유롭게 이용할 수 있는 포맷 아닌가요?

현재 소프트웨어와 웹서비스 두가지를 다 개발하고 서비스하는 입장인데도 OOXML 이던 ODF 이던 별로 크게 관심이 안가네요^^;
OOXML 기반의 새 오피스2007 파일은 애플이 새로 출시한 아이웍 '08의 Pages 워드프로세서 에서도 지원하더라구요. 뭐...전 이쪽으로 지식이 부족한편이기는 하지만, 사용자는 뭐가 어찌됬건 공공기관이 odf를 쓰던말던 편한걸 찾게 된다는 거죠. 마이크로소프트 오피스 2007 을 표준 오피스 프로그램으로 단일화 하자는 쌩뚱맞은 표준화 제안이었다면 저도 벌떡 일어섭니다만, OOXML 을 표준에 넣자고 한건.....;;
MS의 플랫폼들이 언제나 그렇듯이 다소 자기네 소프트웨어 안에서 놀게 만드는 경향이 없지 않아 있는데, 일반 사용자들이 그걸 얼마나 느끼냐는 거죠.MS/애플 양사의 오피스2007 과 iWork 가 OOXML 기반 새 2007 파일포맷을 원활히 호환중이니, 사용자야 ODF 는 별로 신경들을 안쓰시고...
기술적인걸로 보면 OOXML 이 구조적으로 한숨 내쉴수 밖에 없는 부분이 많지만, 사용자들의 생각과 개발 현역에 있는 사람과의 생각차이에서 나올 수 밖에 없는, 한계랄까요.
개인적인 사견입니다만, 전 OOXML도 문서표준으로 되었으면 하네요. ODF는 아무래도 사용자 입장에서 쓸만한 뭔가를 주기에는 임팩트가 부족한 스펙이라고 해야하나요.

전 개발자 입장보다 사용자입장에서, 일반.....아주 초 일반적인 엔드유저 입장에서 바라봤을때 OOXML :)

맥용 오피스 2004는 윈도용과 렌더링이 약간 틀립니다. 맥이 메인컴퓨터라서......:)
애플 아이웍 페이지 프로그램의 경우, 2007파일 불러오기만 가능하네요. 어설픈 지원?^^;;;;

그게, ms office를 이용해서 ooxml을 구현하려면 결국 사야 하잖아요. 씽크프리 오피스든 OOo든 ms office처럼 구현하기는 힘들테니까요. odf는 완벽히(?) 구현하려면 무료로 배포되는 소프트웨어가 있으니까, 그만한 차이가 가장 크다고 보는데요.

저는 다른건 제쳐두고서라도

과연 개발하기가 쉬울거라고 생각하시는지를 여쭤보고 싶습니다.

http://ko.wikipedia.org/wiki/%EC%98%A4%ED%94%88%EB%8F%84%ED%81%90%EB%A8%BC%ED%8A%B8
일단 odf나 오픈오피스에 대해서 약간 모르고 쓴 글 같은게 보이는것 같습니다. -_-
오픈 오피스 말고도 odf지원하는 회사 많습니다.

지원하는 프로그램 목로

많은 자유, 독점 응용 프로그램들이 오픈도큐먼트를 지원하고 있다. 그 중에 두드러진 오피스군으로는 자유 소프트웨어인 오픈오피스 및 상용 소프트웨어인 스타오피스, IBM 로터스 심포니, KOffice, 구글 오피스(Google Docs) 등이 있다.

ODF 표준의 구현 방식 굉장히 다양하기 때문에, 실제 구현 수준과 완성도도 프로그램에 따라 다르다. 따라서 정보 처리 상호 운용 테스트가 필요하다. 오픈도큐먼트 협회에서는 다양한 구현 방식에 따른 테스트와 점수를 공개하고 있다.[4]

오픈도큐먼트 재단과 협력 단체들은 마이크로소프트 社의 제품에서도 오픈도큐먼트를 사용할 수 있는 플러그인과 필터를 개발한다고 밝혔다.[5][6]

마이크로소프트 오피스는 오픈도큐먼트를 지원하지 않지만, 오픈도큐먼트와 오피스 오픈 XML 변환기 [7] 를 통해 포맷을 변경할 수 있다. 이 프로젝트의 결과로 소스포지의 ODF add-in for Word 프로젝트는 마이크로소프트로부터 자금을 지원받았으며, 이 프로젝트의 목적은 BSD 라이선스 하에서 마이크로소프트 오피스를 자유롭게 사용할 수 있도록 하는 것이다. 2007년 초반에 마이크로소프트 워드를 위한 version 1.0을 내놓았으며, 2007년 후반에 엑셀과 파워포인트를 위한 버전을 내놓을 계획이다. 또한 선(Sun) 社에서도 마이크로소프트 오피스 2000, XP, 2003 을 위한 오픈도큐먼트 플러그인을 내놓았다.[8]

현재 odf를 지원하는 회사들은 썬 마이크로 시스템 구글 ibm 어도비 노벨 코렐 노키아
등등 이것 이외에도 수십여 회사들이 더 관여하고 있고
odf를 읽고 쓸수 있는 오피오 스위트도 10여가지 정도 됩니다. -_- 현재 전 맥에서 네오오피스를 사용합니다만 윈도우용 오픈오피스에서 만들어진 문서를 읽는데 아무런 문제는 없는 것 같습니다. 상용화가 목적인 아닌 단체에서는 변경한 부분을 다시 공개한다는 조건으로 소스를 가져다가 써도 무관하기에 가능한 것입니다. 그리고 빠져 있는 기술적 스팩에 대해서 말씀하시고 계신듯 한데 제가 알기론 그 부분에 관해서 다른 회사들과 협의해서 추가하기 위해 많이 남겨두었다고 합니다. 독자적으로 만들려는 포멧이 아니기에 다른 회사들과 기술적인 의견을 수렵해서 차후에 업데이트하려는 계획이지요 -_-
ooxml에 관해서 법적으로 문제가 있는 정도가 아니라 그 관련 스팩들을 모두 구현하려면 특허를 침해 할수 밖에 없고 그로인해서 어떤 회사건 ms에 소송을 당하지 않으리라 보장할수 없다고 고려대 법학과 교수 김기창 교수님께서 오픈웹에 글을 옳린것이 있습니다. 한마디로 ms에 정책은 오픈소스 측에 방해가 될뿐 오픈소스 단채를 공격하는 수단으로 사용할수도 있다는 겁니다. 스팩 구현과 관련되어서도 ms오피스가 아니면 도저희 제대로 구현할수 있는 방법이 없을 정도의 허술하게 많들어 놓은 부분이 한둘이 아니라고합니다. 한마디로 반쪽짜리 공개라는 것이죠 -_-

예를 들자면

- 5.1.11.18 prstGeom(Preset Geometry), DrawingML-Main (p.3672)
Preset shape의 경우 '<a:prstGeom prst="heart"></a:prstGeom>"처럼 해당 shape의 preset name만 문서에 기록되며, path 정보가 없기 때문에, 해당 path를 알고 있는 MS Office만이 preset shape을 정확하게 표현할 수 있다.

- 5.1.11.11 gd(Shape Guide), DrawingML-Main (p.3660)
Shape path를 결정짓는 변수인 adjust value의 경우, shape guide로 그 값이 기록되는데, coordinate space가 정의되어 있지 않아 그 값의 의미를 파악할 수가 없다. 역시 MS Office만이 정확한 coordinate space를 알고 있다.

- 4.6.7 attrName(Attribute Name), PresentationML-Animation (p.3080)
애 니메이션의 경우 특정 개체의 속성을 시간에 따라 변화시켜줘야 하는데, 그 속성이름을 attrName element에 기록한다. 그런데 실제로 PowerPoint 2007로 pptx 문서를 만들어보면 'style.color', 'style.rotation' 등 스펙에 정의된 이름 말고도 'fillcolor', 'r' 등 그네들만이 사용하는 이름이 문서에 기록된다. 심지어는 특정 vendor를 지칭하는 속성 이름들('ppt_x' 등)도 버젓이 기록된다. 만약 스펙에 근거한 개발을 한다면, 저런 속성 이름들은 처리가 불가능해진다.

- 4.6.92 val(Value), PresentationML-Animation (p.3158)
attrName과 마찬가지로 '0-#ppt_y/2'와 같은 말도 안되는 변수를 수식에 넣고 있다.

-----------------------
이런 것들이죠 iso 이런한 자세한 부분까지 전부 컴토하기가 어려울겁니다. 일단 표준안에 통과 된서 표준이 되더라도 ooxml를 완벽하게 지원하는 회사는 ms가 유일하게되는 것이고 그 후엔 ooxml도 표준이라면서 각국정부에 오피스를 납풉하게 되겠지요 그 후 이와 관련된 회사들은 기술호환성 문제등으로 밀려날겁니다.
된통 뒤통수 맞는 거죠 라이센스와 관련되서 이런 기술적 문제는 ms가 해결해주지 않는다면서 소송을 건다면 간단합니다. ms는 이 모든 회사들이 모두 소송 비용으로 파산할정도로 현금아 널널하다는 것이죠 -_-
또한 표준이 지속된다는 아무런 근거가 없습니다. 독자표준안 이기 때문이죠 고로 다음번 표준 업데이트에서 호환성을 위한 기술 스팩 공개가 제대로 될지 아무로 모른다는 겁니다. 현재는 어는 정도 공개하는 것 처럼 보이지만 함정이라는 것이죠
ms는 항상 그래왔습니다. 일단 관련 회사들을 모조리 모아서 협력하는 척하고 그 회사들이 자사 기술을 사용하면 갑자기 돌변해서 관련 회사들이 모조리 망하게 하는 겁니다.
이런 일들이 한두번이 아니었습니다.