OOXML'e Dair Karşı Görüş
PardusWiki sitesinden
Özgün Belge: http://www.noooxml.org/local--files/arguments/TheCaseAgainstOOXML.pdf
Konu başlıkları |
OOXML'e Karşı Mücadele
Bu belge DIS 29500 (Office Open XML - OOXML) ISO ve diğerleri tarafından Uluslararası Standartlar için belirlenmiş kriterlere neden uymadığını açıklamaya çalışmaktadır. Bu belge OOXML'de belirlediğimiz birkaç yüz ciddi açığın seçilmiş bir kısmını irdeler.
Standartların Ölçülme Kriterleri
“Standart” nedir? İlgili birkaç tanım mevcuttur. ISO tanımı:
"Fikir birliği ile ortaya konmuş ve tanınan bir topluluk tarafından onaylanmış, çeşitli eylemler ve sonuçları için ortak ve tekrarlanabilen kullanım sağlamak amacıyla kurallar, yönergeler ve karakteristik özellikler temin eden, verilen bir durumda mümkün olan en iyi düzeni ve sonucu elde etmeye yönelik [bir] belge.
NOT Standartlar bilim, teknoloji ve tecrübenin birleştirilmiş sonuçlarını temel almalı ve en yüksek toplumsal faydayı elde etmeyi amaçlamalıdır." [1]
BSI British Standards:
“... bir standart, bir şeyi yapmanın üzerinde anlaşmaya varılmış ve tekrarlanabilen yoludur. Bir kural, yönerge veya tanım olarak devamlı bir şekilde kullanılmak için tasarlanmış bir teknik belirtim veya diğer kesin ve açık kriterleri içeren yayımlanmış bir belgedir. Standartlar hayatı kolaylaştırmaya ve kullandığımız pek çok servis ve eşyanın güvenilirliğini ve etkinliğini arttırmaya yardımcı olur. Belirli bir amaca yönelik olmaları ve genel uygulama yerine en iyi uygulamayı özetlemeleri hedeflenir. Standartlar belirli bir malzeme, ürün, işlem veya servisin üretici, satıcı, alıcı, kullanıcı ve düzenleyicileri gibi konuyla ilgili tüm grupların tecrübe ve uzmanlıkları bir araya getirilerek oluşturulur." [2]
ISO/IEC HTC1 Direktifleri:
"BT (Bilişim Teknolojileri - IT) standartlaştırmasının amaçlarından biri, pazardaki ürünlerin birlikte çalışabilirlik, taşınabilirlik, ve kültürel ve dilbilimsel uyum sağlanılabilirliğini garantilemektir. Bu nedenle, geliştirilen standartların şu Ortak Stratejik Karakteristiklerin gereklerini karşılayabilmesi gerekir:
- Birlikte çalışabilirlik; - Taşınabilirlik; - Kültürel ve dilbilimsel uyum sağlanılabilirlik." [3]
Bu ve diğer ulusal tanımlardan, standartların ne yapması gerektiğine dair bazı ortak temalar çıkmaktadır:
- Kesin ve açık bir biçimde, bir şeyin tekrar edilebilir bir şekilde yapılabilmesi için ortak kriterleri tanımlarlar.
- Verilen bir durumda mümkün olan en yüksek düzeni ve sonucu sağlamalıdırlar; amaca yönelik olmalı, bilim, teknoloji ve tecrübenin, genel uygulamadan ziyade en iyi uygulanışlarının birleştirilmiş bir özetini oluşturmalıdırlar.
- Birlikte çalışabilirliği ve taşınabilirliği cesaretlendirmelidirler.
- Farklı dil ve kültürlere adapte olmalıdırlar.
Bu belge, DIS 29500 (Office Open XML - OOXML) bu kriterler kapsamında değerlendirmektedir. OOXML belirtimindeki bazı problemlere örnekler verilmiştir, ancak bu örnekler yüzlerce maddelik bir listenin çok küçük bir kısmını oluşturmaktadır. OOXML'deki ciddi problemlerin çokluğu bir belirtim olarak gelişmemişliğini ve bir ISO standardı olarak hızlıca onaylanmasının uygunsuzluğunu göstermektedir.
Kesin ve Açık, Tekrarlanabilir, Ortak
Bu kriterler bir standardın teknolojinin ortak uygulaması için detaylı ve yazılı bir açıklaması olmasının gerekliliğine işaret etmektedir.
İlk olarak, OOXML'in Kelime İşleme İşaretleme Lisanı (WordProcessingML) kısmı, Microsoft'un eski uygulamalarının çeşitli davranışlarıyla ilgili bilgi depolama yeteneği sağlamak için çok sayıda "Uyumluluk Ayarı" [4] listelemektedir. Bu ayarların "WW8gibiDipnotYerleşimi" (footnoteLayoutLikeWW8), "Word95gibiOtomatikBoşluk" (autoSpaceLikeWord95) ve "Word97SatırBölmeKurallarıKullan" (useWord97LineBreakRules) gibi isimleri bulunur[5]. Ancak, OOXML belirtimi bu ayarların yalnızca isimlerini verir. Onları tanımlamaz. Bu ayarların ne anlama geldiğini yalnızca Microsoft bilmektedir, fakat onlar için kesin tanım vermeyi reddetmektedir. Onun yerine, OOXML okuyucuyu eski yazılım uygulamalarına yönlendirmektedir:
"Bu davranışın aynî bir benzerini yapabilmek için, uygulamalar o uygulamanın pek çok olası davranış içeren ve bu OOXML Standardı'na aynen aktarılması mümkün olmayan o davranışını taklit etmelidir. Eğer uygulamalar bu davranışla eşleşmek istiyorlarsa, o uygulamaların çıktılarını kullanmalı ve çoklamalıdırlar."
Bu, açıkça görülüyor ki, kesin ve açık değildir ve kesinlikle bu özelliklerin tekrarlanabilir olmasına veya ortaklaşa uygulanmasına imkân vermez. İçeriye OOXML alabilen (OOXML biçiminde veri alabilen) bir uygulama, bu nitelikleri kullanan bir belge verildiğinde, onları düzgün bir şekilde yorumlayamayacak ve sayfayı yüksek bir doğruluk oranında oluşturamayacaktır. Üstelik, bu nitelik tanımlanmadığı, sadece listelendiği için, "Microsoft Ofis belgelerine yapılan büyük miktardaki yatırımla tamamen uyumlu olma"[6] (yayımcılarına göre OOXML'in amacı) özelliğinden faydalanabilme Microsoft'a ayrılmıştır. OOXML standardı bu yararın tekrarlanabilirliğini ve ortak kullanımını sağlamamaktadır.
İkinci olarak, OOXML'in WordProcessingML bölümü çeşitli yazma sistemleri, lisanlar ve mesleki kullanımlar için çok sayıda numaralama biçimi listelemektedir. [7] Bunlara "chicago", "sayısalİdeogram" (ideographDigital), "gelenekselResmîİdeogram" (ideographLegalTraditional), "koreSayısal2" (koreanDigital2) ve "koreResmî" (koreanLegal) gibi isimler verilmiştir. Bunlar sadece isim etiketleridir ve yine, kesin ve açık bir şekilde tanımlanmamışlardır. OOXML belirtimini gerçeklemek isteyeceklere, "Kore Resmi Numaralaması" adında bir şeyin varolduğu söylenmiştir, ancak bunun ne anlama geldiği ve kendi uygulamalarında nasıl gerçekleyecekleri söylenmemektedir.
Örneğin, Kore'de OOXML'i uygulamasında gerçeklemek isteyecek birisi, Chicago Biçim El Kitabı için herhangi bir basım numarası (15 basımı bulunmaktadır) veya sayfa numarası verilmeyen ama "...seri Chicago Biçim El Kitabı'nda belirtilen karakterlerden oluşmalıdır" şeklinde açıklanan bir numaralama biçiminden ötürü ne yapacağını bilemeyecektir. OOXML belirtimi, bu özelliklerin tekrarlanabilir, ortak bir kullanımına imkân vermemektedir.
Üçüncü olarak, OOXML'in Hesap Tablosu İşaretleme Lisanı (SpreadsheetML) kısmı bir "güvenlikTanıtıcısı" (securityDescriptor) sıfatı içermektedir ve belirtime göre bu sıfat: [8]
"... bu hücre aralığına parola vermeden ulaşabilecek kullanıcı hesaplarını tanımlar. Bu sıfatı kaldırmak bu hücre aralığı için kullanıcılara verilen veya verilmeyen bütün izinleri kaldırmalıdır."
Bu sıfat, uygulamaya hangi kullanıcıların bir hesap tablosundaki bir hücre aralığını parolasız olarak değiştirmesine izin verildiğini söyleyen, güvenlikle ilgili ve önemli bir özelliktir. Bu özelliği gerçeklemek isteyen bir programcının bu kullanıcı hesaplarının belgede nasıl betimlendiğini bilmesi gerekmektedir. Birbirlerinden virgülle mi ayrılmışlardır? Noktalı virgülle mi ayrılmışlardır? Boşluk karakteriyle mi ayrılmışlardır? OOXML birden fazla ada izin verildiğini ima etmesine rağmen bu detayları vermemektedir. Ayrıca, sayısal kimlik için evrensel bir bağlam yoktur. Her birimizin, elektronik posta için, veritabanı için, makineye erişim için, alan denetleyicileri için, LDAP vb. için birden fazla kullanıcı hesabı bulunur. Burada hangisi kastedilmektedir? Bu özellik nihai olarak tekrarlanabilir ve ortak kullanımın ana unsuru olan birlikte çalışabilirlik açısından yeterli tanım içermemektedir.
Özet olarak, OOXML'in pek çok alanı ya tanımsızdır ya da yeterince tanımlanmamıştır. Belirtim Microsoft'a kendi belgelerini betimlemede kayda değer bir çerçeve sunmasına rağmen, bu nitelik başkalarına da aynı faydaları elde etmeleri için eşit ulaşım hakkı ve imkânı tanımaya yaklaşmamaktadır bile. Sorulacak soru, "OOXML iddia edilen yararlarının tekrarlanabilir ve ortak uygulanabilir olduğu kesin ve açık bir dosya biçimi tanımlamakta mıdır?" sorusudur. Yukarıdaki üç örnek ve daha niceleri, OOXML'in bu kriteri karşılayamadığını göstermektedir. Bir standart olarak olgun olmayışı, ki bu birden fazla tam nitelikli uyarlamasının olmayışıyla da kendini göstermektedir, ve evvelden yapılması gereken teknik gözden geçirmesinin yetersiz olması, onu hızlıca uyarlanmaya uygunsuz hale getirmektedir ve bir Uluslararası Standart olarak tasdik edilmek için zayıf bir aday yapmaktadır.
Kabul Gören, Birleştirilmiş En İyi Uygulamalar
Bir ISO Standardı tek bir şirketin bir ürününün, o şirket alanında ne kadar baskın olursa olsun, işletim karakteristiklerinin güncel ve detaylı kaydı olmamalıdır. Daha önce verdiğimiz üzere, ISO'nun ve diğerlerinin tanımından, Uluslararası bir Standart "bilim, teknoloji ve endüstrinin birleştirilmiş sonuçları"nı temsil etmelidir. Bir standart, "kabul görmeli"dir. Diğer bir deyişle, tek bir sağlayıcının bir işi yerine getirme yolunu göstermemelidir. Uzmanların ortak fikirleri doğrultusunda "en iyi uygulamaların özeti"ni sağlamayı amaçlamalıdır. Bir teknolojinin tekrarlanabilen ve ortak uygulanışının en iyi yolunu öğretmelidir.
Endüstri en iyi uygulamalarını standartlaştırma yoluyla kaydeder. Varolan belge ve işaretleme standartları gözden geçirilmiş, onaylanmış ve uygulanmakta olan en iyi uygulamaları temsil etmektedir. Dünya Çapında Ağ Birliği (World Wide Web Consortium -W3C) [9] işi XHTML, CSS2, XSL, XPath, XForms, SVG, MathML ve SOAP gibi ilgili olanlar da dahil XML ve ilgili teknolojilerinin omurgasını oluşturan çekirdek XML standardının sürekliliğini sağladıkları için, XML belge biçimleriyle doğrudan ilgilidir.
Öte yandan, OOXML endüstrinin kullanımda olan en iyi uygulamalarının çok azını kapsamaktadır. Daha da kötüsü, OOXML gerçekleyicilerinin, ilgili ve daha üstün W3C standartları bulunmasına rağmen, Microsoft'un geçmişten gelen sahipli biçemlerini kullanmaları istenmektedir.
Örneğin, Yöney İşaretleme Lisanı (Vector Markup Language - VML) Microsoft tarafından geliştirilmiş ve 1998 yılında W3C'ye teklif olarak sunulduğunda bir teknik komite tarafından incelenmiş ve reddedilmiştir. Endüstri onun yerine W3C tarafından geliştirilip bir standart haline getirilen ve büyük oranda benimsenen Ölçeklenebilir Yöney Grafikleri'ni (Scalable Vector Graphics - SVG) desteklemiştir. XML yöney grafikleri için SVG neredeyse 10 yıldır standarttır. Ancak OOXML sahipli VML'yi kullanmaktadır, çünkü Microsoft Internet Explorer'e standart olan SVG yerine sahibi olduğu VML'yi entegre etmiştir.
Microsoft yöney grafikleri kullanımı için VML'nin yanlış bir standart olduğunu kabul etmiştir:
"VML biçimi Office 2000 ile piyasaya sürülen eski bir biçimdir ve bu standarda geriye uyumluluk sebebiyle dahil edilmiş ve tam olarak tanımlanmıştır. Çizim İşaretleme Lisanı (DrawingML) biçimi Ofis Açık XML biçimlerinde VML'nin kullanımının zamanla yerini alması hedeflenen daha yeni ve daha zengin bir biçemdir. Artık geçerliliği kalmamış olan VML OOXML'de sadece geçmişte kullanılması sebebiyle bulundurulmaktadır ve çizimler için bir dosya biçemine ihtiyaç duyan yeni uygulamaların tercihan Çizim İşaretleme Lisanı'nı kullanmaları esasen tavsiye edilmektedir." [10]
Varolan standart SVG'yi kullanmak yerine, Microsoft OOXML yöney grafikler için iki farklı işaretleme lisanı içerir. Bunların biri 1998'de W3C tarafından reddedilmiştir, diğeri de endüstriden habersiz olarak geliştirilmiştir. OOXML'i uyarlamak isteyenler için bunun getirdiği ek iş çok büyük boyutlardadır. Uyarlayıcılar, kullanıcılara hiçbir ek getiri sağlamamasına rağmen, aynı fonksiyon için ikisi de standart olmayan iki farklı işaretleme yapısına destek vermek zorunda kalacaktır. Office yazılımında önceden varolan VML desteği sayesinde, bundan sadece Microsoft yararlanacaktır.
Üstelik, metinden daha da ziyade, yöney grafiklerinin dosya biçemi dönüştürücüler tarafından mükemmel bir şekilde dönüştürülmesi olanaksız görünmektedir. Dolayısıyla yöney grafiklerinin ikisi OOXML'de olmak üzere gereğinden fazla sayıda olması dönüştürme sırasında uyumluluk problemlerine sebep olacaktır.
Bu kulağa yüksek gayeli gibi gelmekte midir? En iyi uyarlamaları kullanıyor mudur? Aksine, OOXML belirtimine eklenen 600 sayfalık "VML gereksinimleri" Microsoft dışında kimseye yarar sağlamamaktadır ve gerçekte OOXML'i uyarlamak isteyenlerin önüne sarp engeller koymaktadır.
İkinci bir örnek olarak, hesap tablosu tarihleri ile ilgili olarak aşağıda verilen gereksinimi inceleyiniz:
"Kalıt ve miras nedeniyle, 1900 taban tarih sistemini kullanan bir uyarlama 1900 yılını bir artık yıl olarak görmelidir... Bunun bir sonucu 1 Ocak ile 28 Şubat arasındaki tarihlerde, HAFTANINGÜNÜ (WEEKDAY) doğru günün bir öncesinin değerini döndürmelidir, ki böylece (varolmayan) 29 Şubat tarihi Şubat 28'den hemen sonraki ve 1 Mart'tan hemen önceki günü döndürmelidir." [11]
Diğer bir deyişle, dünya çapında ticaret, bilim ve hükümetlerin temel takvimi olan Miladî Takvim, "geriye dönük uyumluluk nedeniyle" bir kenara bırakılmaktadır. Sonuç, OOXML'i uyarlayacakların uygulamalarının, eğer OOXML standardına uymak istiyorlarsa, kullanıcılardan gelen "1 Şubat 1990 haftanın hangi günüdür?" gibi sorulara yanlış cevaplar vermesini gerektirmektedir. Bu sık kullanılan ve Miladî Takvim'in kullanılmasını gerektiren Yapısal Sorgulama Lisanı (SQL) yoluyla ilişkisel veritabanlarıyla hesap tablosu verisi alışverişinde bulunma işinde hususî problemlere neden olmaktadır. [12]
Üçüncü bir örnek olarak, OOXML "ikili bir temel katar tipi" [13] olarak "Temel Katar" denen bir katar (string) tipi tanımlamaktadır. Bu yeni katar tipinin özelliklerinden birisi, XML-dışı (kontrol karakterlerinin) kodlanmasına izin vermesidir. Ancak, bir XML belgesinde XML dışı karakterlerin bulunması, XML ile ve XML temelli araçlarla ortak çalışabilirliği bozmaktadır. W3C'nin Uluslararasılaştırma Eylemi bu uyarlamayı şu şekilde nitelemektedir:
"Kontrol kodları uygun işaretleme ile değiştirilmelidir. XML yapısal verinin kodlanması için standart bir yol sağladığından, kontrol kodlarının işaretleme dışında bir biçimde ifade edilmesi XML kullanmanın asıl avantajlarını geçersiz kılmaktadır. HTML'de ve XHTML'de kontrol kodlarının kullanılması, bu işaretleme lisanları veriyi değil metni temsil ettikleri için asla uygun değildir." [14]
Dördüncü olarak, birkaç noktada [15], OOXML birden fazla Boole (true-false) değeri tek bir tamsayı içinde belirtebilmek için "bit maskeleri" kullanmaktadır. Bu 20 yıl önce hafıza miktarı çok kısıtlıyken ve C diliyle program yazarken ortak bir yöntem olmasına rağmen, XML'de çok kötü bir biçim olarak kabul edilmektedir. XSLT gibi standart XML araçları ile işlemeyi, bu araçlar veriyi bit düzeyinde etkili bir şekilde işlemeyi sağlayacak özellikler içermediği için, çok zor kılmaktadır.
Beşinci olarak, OOXML yalnızca bilim, endüstri ve tecrübe açısından en iyi uyarlamaları birleştirmekten değil, Microsoft'un kendi en iyi uyarlamalarını dahi birleştirip sağlamlaştırmaktan yoksundur. OOXML yazdırma ayarlarının (yazdırılacak sayfa sayısı, hangi sayfaların yazdırılacağı, sayfa yönelimi, yazdırma kalitesi, vb.) plâtforma özel ikili bir biçimde saklanmasını salık vermektedir. Örneğin Windows'da onların öğüdü yazdırma ayarlarını "DEVMODE" denen bir yapıda saklamaktır. Oysa böyle yapmak yazdırma ayarlarını platforma bağımlı hale getirecektir ve birlikte çalışabilirliği engelleyecektir. Ama aynı zamanda, Microsoft'un yeni belirtimi "XML Kâğıt Belirtimi" (XML Paper Specification - XPS) Microsoft'un hakkında şunları söylediği bir YazdırmaBileti (PrintTicket) öğesi içermektedir:
"YazdırmaBileti teknolojisi mevcut DEVMODE yapısının ardılıdır. Genişletilebilir İşaretleme Lisanı (eXtensible Markup Language) temelli, iş biçimlendirme ve yazdırma işi yapılandırması hakkındaki bilgileri belirten ve saklayan bir belgedir... Mevcut yazdırma altsistemiyle ilişkili olan YazdırmaBileti teknolojisi yazdırma altsisteminin tüm bileşenlerinin ve istemcilerinin DEVMODE yapısının umumî ve hususî kısımlarında saklanan bilgiye iyi tanımlanmış bir XML biçemi kullanarak saydam bir şekilde erişmesini mümkün kılmaktadır." [17]
OOXML Microsoft'un kendi tavsiye ettiği uyarlaması "iyi tanımlanmış bir XML biçimi"ne geçmek iken niçin taşınabilir olmayan, eskimiş, ikili, platform ve uygulama bağımlı yazdırma ayarlarını almaktadır?
Altıncı bir örnek olarak, OOXML standart olmayan birkaç şifreleme algoritması tanımlamaktadır [18]. Bir ISO/IEC 10118-3:2004 algoritması veya NIST tarafından FIPS-180 uyumlu algoritmalar listesindeki kullanımı onaylanmış algoritmalardan [19] birini kullanmak yerine (ki SHA-256 gibi, iki listede de bulunanlar da vardır) OOXML muhtemelen Microsoft Office'nin önceki sürümlerinden birinde kullanılmış olan kalıt bir karıştırma algoritması belirtir. Bu bilim, endüstri ve tecrübenin en iyi uygulamaları birleşimini mi salık vermektedir? Aksine, Microsoft bu algoritmaların kullanılmasını tavsiye bile etmemektedir. Onun yerine, Office 2007'de OOXML'e belgelendirilmemiş bir genişleme olarak Belge Hakları Yönetimi (Document Rights Management - DRM) tabanlı koruma sağlamaktadırlar. Bu DRM belgelendirilmemiş olduğu için, başka hiçbir sağlayıcı bu özellikleri özgürce kullanamayacaktır. Office 2007 ile şifrelenmiş belgeler başka hiçbir yerde açılamaz. OOXML uyarlayıcılarının elinde sadece OOXML'in FIPS-180 uyumlu bile olmayan, kusurlu ve kalıt güvenlik desteği kalmaktadır. Yine, Microsoft en iyi uyarlamaları kendine saklamaktadır ve OOXML belirtimini kötürüm güvenlikle bırakmaktadır.
Özet olarak, OOXML tek bir sağlayıcının ikili belge biçimlerinin direkt aktarımıdır. Varolan ilgili uluslararası standartların yeniden kullanılmasından kaçınılması ve Microsoft'un kendi tercihi olan teknolojilerin tutarsız kullanımı, OOXML'in bilim, endüstri ve tecrübenin birleşik sonuçlarını temsil etmediğini göstermektedir. Amaca yönelik değildir. Tek bir sağlayıcının biçemindeki verilerin okunması için bir teknik sağlayabilmesine rağmen, bu, en iyimser ifadesiyle, onu sadece teknik bir belirtim yapmaktadır. Endüstrideki en iyi uyarlamaların birleşimini ve bir ISO standardının tanımlayıcı bir kalitesini temsil etmediği için, OOXML belirtimi bir Uluslararası Standart olarak onaylanmamalıdır.
Birlikte İşleyebilen ve Taşınabilir
Taşınabilirlik ve birlikte çalışabilirlik JTC1'in "Ortak Stratejik Karakteristikler"inin [20] ikisidir, dolayısıyla da JTC1 tarafından onaylanmış tüm standartların temel gereksinimlerindendir. Belge biçem standartları alanında soru, teklif edilen OOXML belirtiminin birden fazla işletim sisteminde birden fazla uygulama tarafından uyarlanabilir olup olmadığıdır. Veya, acaba yalnızca tek bir sağlayıcının uygulamasının faydalanması için özel olarak mı yazılmıştır?
İlk olarak, birlikte çalışabilirliğin önemli bir kısmı hesap tabloları ile ilişkisel veritabanları arasında alışverişinin mümkün olmasıdır. 10 yılı aşkın süredir pek çok hesap tablosu sağlayıcısı tarafından pek çok meslekî süreç bu yetenek üzerine hazırlanmıştır. Ancak, modern veritabanlarında 1900'den çok daha önceki yılların ifade edilmesi mümkünken, OOXML 1900 yılından önceki tarihlerin ifade edilmesi için bir yol sunmamaktadır. Örneğin IBM'in DB2 veritabanı sistemi geriye doğru M.S. 1 yılına kadar olan tarihleri desteklemektedir. Oracle geriye doğru M.Ö. 4712 yılına kadar olan tarihleri desteklemektedir. OOXML belirtimi uyarlayıcıların istedikleri kadar geri bir tarihi kullanmalarını önlememelidir. Bir uygulama sağlayıcısı doğal olarak hesap tablosunun tarih desteğinin veritabanının yetenekleriyle eş olmasını isteyecektir. OOXML niçin Microsoft Excel'in yetenekleriyle sınırlıdır? Bu hesap tabloları ile veritabanları arasında birlikte çalışabilirliği baltalamaktadır.
İkinci olarak, OOXML bir grafik nesne ile kullanılabilecek pano biçimlerini kaydeden bir ST_CF tipi [21] tanımlamaktadır. Bu tipte kullanılabilen tüm değerler (EMF, WMF, vd.) sahipli Windows biçimleridir. Diğer işletim sistemleri tarafından kullanımlarına izin yoktur. Örneğin, Linux'ta resimler genellikle panoya PNG gibi bir standart biçimde kopyalanmaktadır. Ama bir sağlayıcı bu tipteki bir belge kaydına "PNG" kodlarsa, belge geçersiz olacak ve belge ve uygulama OOXML belirtimine uymayacaktır.
Üçüncü olarak, HesapTablosuİL'de (Hesap Tablosu İşaretleme Lisanı - SpreadsheetML) bulunan bir parola karıştırma algoritmasının tanımı, büyük ihtimalle Excel'den seçilip alınmış 5 sayfalık C dili kaynak kodu [22] olarak verilmiştir. Ancak, bu kodun bit düzeyi işlemleri makine-bağımlıdır ve işlemci mimarisine göre farklı sonuçlar doğuracaktır. Bir makinede oluşturulan bir belge başka bir makinede okunamaz olabilir. OOXML bu fonksiyonun taşınabilir bir tanımını sunmamıştır.
Dördüncü olarak, KelimeİşlemeİL'nin (Kelime İşleme İşaretleme Lisanı - WordProcessingML) "taratıcıİçinEniyileştir" (optimizeForBrowser) elemanı [23] Internet Explorer dışındaki tarayıcıların varlığını gözardı eden bir şekilde tanımlanmıştır. Peki ya Mozilla Firefox? Safari? Opera? Bunların hiçbiri hedef tarayıcı olarak ayarlanamamaktadır. OOXML'in bu kısmı "hedef web tarayıcısı ile uyumlu olmayan tüm ayarlar kapatılmalıdır," demektedir. Ya ben uygulamamın standartlarla uyumlu çıktı üretmesini istiyorsam? Yani PNG'ye "evet", VML'ye "hayır", MathML ve SVG'ye "evet"? Bir uyarlayıcının OOXML'in mevcut tasarımıyla bunu belirlemesi mümkün değildir.
Beşinci olarak ÇizimİL'nin (Çizim İşaretleme Lisanı - DrawingML) "Slayt Senkronizasyon Nitelikleri" [24] bir sunumun bir sunucuda merkezi olarak depolanmış olan slaytlarla slayt içeriğini senkronize etmesi imkânını sağlıyor. Bu Microsoft PowerPoint ve SharePoint'in bir özelliği. Ancak, OOXML'de bu özelliğin tanımı yeterli detaydan yoksun. İletişim protokolü nedir? Veri modeli nedir? Bu tür istemci-sunucu protokollerini açıklamak için standartlar (Web Servis standartları) bulunmasına rağmen, OOXML hiçbir bilgi vermiyor. Bu fonksiyonun birlikte çalışabilir bağımsız uyarlamaları engelleniyor ve varolan tek uyarlama SharePoint'e bağlı kalıyor.
Özet olarak, OOXML diğer teknolojilerden söz ettiği noktalarda, halihazırda sadece Microsoft Office tarafından desteklenen teknolojilere bağımlı kılan bir yol izliyor. Bazı durumlarda OOXML'e VML gibi diğer belirtimleri dahil etmek için fazladan çaba harcanmış durumda. OOXML alternatif standart ve açık teknolojileri gözardı etmekle kalmıyor, diğer sağlayıcıların diğer teknolojilerle birlikte çalışabilme desteği eklemesini de imkânsız kılıyor. Tüm sağlayıcılar kendi tasarım kararları ve kendi öncelikleri ile sınırlı olmalarına rağmen, bir ISO standardının taşınabilirlik ve ortak çalışabilirlik niteliklerine sahip olması gerekir, ki bu sayede tüm sağlayıcılar kendi tasarım kararı ve öncelik haklarına sahip olsunlar. OOXML'in Microsoft'un çözüm ve platformlarıyla çok iyi çalışan ama diğerleriyle çalışmayan keyfi kısıtlamaları teklif edilen belirtimi bir Uluslararası Standart olarak uygunsuz hale getirmektedir.
Kültürel ve Dilbilimsel İntibak Kabiliyeti
OOXML'in özellikleri Microsoft Office'in nitelik kümesinden geldiği için, bu nitelik kümesinin Microsoft'un büyük başarılar sağladığı gelişmiş ülke ve toplumların ihtiyaçlarını en iyi şekilde karşılaması şaşırtıcı değildir. Ancak, bir Uluslararası Standart daha geniş bir açıdan bakmalı ve geniş kültürel ve dilbilimsel ortak işbirliktelik sağlamalıdır.
Endişe kaynağı olabilecek bir örnek, İŞGÜNLERİ (NETWORKDAYS) hesap tablosu fonksiyonudur [25]. Bu fonksiyon OOXML tarafından iki tarih arasındaki işgünlerinin sayısını haftasonlarını gözardı ederek döndürmek üzere tanımlanmıştır. Bazı kültürler için, haftasonu Cumartesi ve Pazar'dır. Bazıları içinse dinlenme günleri Perşembe-Cuma veya Cuma-Cumartesi'dir. OOXML "haftasonu"nu tanımlamaz ve kullanıcıya bunu tanımlama imkânı da sağlamaz. Excel'de tanımlandığı şekliyle fonksiyon haftasonunun her halükârda Cumartesi-Pazar olduğunu varsaymaktadır. Bu hesap tablosu fonksiyonu Dünya çapında belki de milyarlarca insan açısından cevabı hatalı kılacak şekilde tanımlanmıştır. OOXML kültürel uyum sağlama yeteneğinden yoksundur. Bunu kullanıcının varsayılan haftasonu tanımını değiştirmek için ek bir parametre geçmesine izin veren OpenDocument biçimiyle karşılaştırabilirsiniz.
İkinci olarak, KelimeİşlemeİL'nin (WordprocessingML) sayfa kenarlığı olarak kullanılabilecek çok sayıda grafik kenarlık listeleyen "Kenarlık Biçimleri" (Border Styles) denen bir özelliği bulunmaktadır [26]. Bu, adları ve grafikleri önceden belirlenmiş kenarlık biçimleri içeren kapalı bir listedir. Bu listeden iki grafik Şekil 1'de gösterilmiştir.
| earth1 (Dünya Sanatsal Kenarlığı) | Dünyanın tekrarlanan bir resminden oluşan bir sanatsal kenarlık belirtir (iki örnek gösterilmiştir):
|
| earth2 (Dünya Sanatsal Kenarlığı) | Dünyanın tekrarlanan bir resminden oluşan bir sanatsal kenarlık belirtir (iki örnek gösterilmiştir):
|
Şekil 1:
Örnek 1: Sayfa Kenarlıkları
Bunlar sayfa kenarlığında yerküreyi göstermek için sunulan iki yoldurve başka yol yoktur; ve ikisi de Asya'yı içermemektedir. Benzer şekilde, doğum günü pastaları, Sevgililer Günü, aşk tanrısı resimleri, boyanmış Paskalya yumurtaları, yılbaşı zencefilli kurabiyeleri, Cadılar Bayramı, Kabak Oymaları ve Batı kültürel çevresine uygun ama başka yerlerde kısıtlı kullanımı olan başka resimler içermektedir. Buradaki problemler bu sayfa kenarlığı listesinin kapalı bir liste olması ve Microsoft Word'un sunduklarının birebir aynısı olmasıdır. Bir OOXML uyarlayıcısı bu listeyi müşterilerinin kültürüne uyan başka resimler kullanarak genişletemez. Eğer genişletirse, belgeleri geçerli OOXML belgeleri olmayacaktır ve standart olmayan resimlerin sayfa kenarlığı olarak kullanılmasını mümkün kılan uygulama OOXML belirtimiyle uyumsuz olacaktır. OOXML diğer kültürlere ne kadar uyumludur? Sayfa kenarlıkları incelendiğinde, bu uyumu sunmaktan uzaktır.
Üçüncü olarak, daha önce belirtildiği üzere, KelimeİşlemeML numaralanmış listeler için bir dizi numaralama biçimi tanımlamıştır [27]. Bu numaralama biçimleri sadece adlandırılmıştır, tanımlanmamıştır. Aynı zamanda bu biçimler kapalı bir liste olarak sunulmuştur, yine Microsoft Word'un destekledikleriyle eşleşmektedir ve yine diğer sağlayıcılar tarafından genişletilebilir değildir. Ancak, sunulan liste tamamlanmamıştır; örneğin, Ermenice, Tamilce ve Yunanca alfabetik, Etiyopya ve Kamboçya numaralı, ve bilim ve eğitim çevrelerinde kullanılan daha pek çok tarihî numaralama biçimini içermemektedir. Tercih edilen çözüm, OpenDocument biçimi ve W3C'nin XSL:FO'su tarafından kullanıldığı üzere, tanıtan-oluşturan bir yaklaşım kullanmaktır. Bu, her biri kendini tanımlayan, açık uçlu bir numaralama biçimi listesine imkân sağlamaktadır.
Kültürel ve dilbilimsel intibak OOXML'de çok kısıtlıdır, çünkü OOXML, Microsoft Office'in bugün sunduklarıyla tam olarak aynı olmasına rağmen, kapalı uçlu bir liste sunmaktadır ve sağlayıcılar tarafından birlikte çalışabilir şekilde genişletilebilir değildir.
Özet
Standartların da standartları vardır. Bu belge, teklif edilen OOXML belirtimini ISO tarafından bir standardın nasıl olması gerektiğine dair oluşturulan kriterler kapsamında değerlendirerek, OOXML'in hangi noktalarda ISO standartlarının istenen hangi karakteristiklerini karşılayamadığını açıklamıştır: kesinlik, ortak kriterler, en iyi düzen derecesi, bilim, teknoloji ve tecrübenin en iyi uyarlamalarını birleştirme, birlikte çalışabilirlik, taşınabilirlik ve kültürel ve dilbilimsel uyum sağlayabilirlik. Çok sayıda örnekle, teklif edilen OOXML standardının bu açılardan yetersiz kaldığını göstermeye çalıştık. Bu kriterleri karşılayamayarak, OOXML mümkün olan en yüksek kamu yararını sağlamakta başarısız olmuştur.
Bir belge biçemi standardından beklenenler yüksektir ve öyle de olmalıdır. Yukarıda sayılan kriterleri karşılayabilen standart bir belge biçemi sayısal mirasımızın uzun vadede korunmak, tüm vatandaşların hükümet belge ve kayıtlarına eşit ulaşım hakkını temin etmek, ve belge tabanlı meslekî işlem eşgüdümü ve heterojen sistemlerde iş akışı maliyetleri açısından etkili ve etkin sonuç elde etmek için elzemdir. Microsoft Office'nin belge biçemi OOXML, bu faydaları sağlamaz ve bir ISO standardı olmaya uygun değildir. JTC1'in bu oylamada onaylamaması beklenmektedir.
-IBM'den Rob Weir ve diğerlerinin katkıları üzerine kuruludur.
Dipnotlar
(1): ISO/IEC Kılavuzu 2:2004, tanım 3.2. Çeşitli ulusal standartlaşma yönetim kurulları da (örneğin Almanya DIN) bu ISO tanımını kabul etmiştir.
(2): http://www.bsi-global.com/en/Standards-and-Publications/About-standards/What-is-a-standard/
(3): JTC1 Direktifleri, Basım 5, Sürüm 3.0, Bölüm 1.2
(4): Bölüm 4, Kısım 2.15.3.9. Tüm OOXML kısımları http://www.ecma-international.org/publications/standards/Ecma-376.htm adresinde bulunan Ecma 376 "Ofis Açık XML" belirtiminden alınmıştır.
(5): Diğer bazı örnekler: Word6gibiSatırSarma (lineWrapLikeWord6), mwKüçükBüyükHarfler (mwSmallCaps), WW8gibiŞekilYerleştirme (shapeLayoutLikeWW8), WPÜstBoşluğuYokEt (supressTopSpacingWP), fontYükseklikleriniWP6gibiKes (truncateFontHeightsLikeWP6), Word202TabloBiçimKurallarınıKullan (useWord2002TableStyleRules), wpHizalama (wpJustification) ve wpBoşlukGenişliği (wpSpaceWidth)
(6): Bölüm 1, Giriş
(7): Bölüm 4, Kısım 2.18.66
(8): Bölüm 4, Kısım 3.3.1.69
(9): http://www.w3.org
(10): Bölüm 4, Kısım 6.1
(11): Bölüm 4, Kısım 3.17.4.1
(12): Veritabanı Lisanı SQL - Bölüm 2: Temeller (ISO/IEC 9075-2:1999), Kısım 4.7.3
(13): Bölüm 4, Kısım 7.4.2.4
(14): http://www.w3.org/International/questions/qa-controls
(15): Örneğin, Bölüm 4, Kısım 2.3.1.6; Bölüm 4, Kısım 2.4.51; Bölüm 4, Kısım 2.4.52; Bölüm 4, Kısım 2.4.7, vb.
(16): Bölüm 1, Kısım 15.2.14
(17): http://msdn2.microsoft.com/en-us/library/ms715246.aspx
(18): Örneğin, Bölüm 4, Kısım 2.15.1.28'de
(19): http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
(20): JTC1 Yönergeleri, Basım 5, Sürüm 3.0, Kısım 1.2
(21): Bölüm 4, Kısım 6.4.3.1
(22): Bölüm 4, Kısım 3.2.29, sayfa 1917
(23): Bölüm 4, Kısım 2.15.2.32
(24): Bölüm 4, Kısım 4.7.1
(25): Bölüm 4, Kısım 3.17.7.224
(26): Bölüm 4, Kısım 2.18.4
(27): Bölüm 4, Kısım 2.18.66
