Кажете НЕ на ISO стандратизацията на Microsoft Office формата

Желая националните стандартизационни комитети членове на ISO да гласуват „ПРОТИВ“, в гласуването за приемане на спецификацията ISO DIS 29500 (Office OpenXML или формат OOXML) като стандарт, поради следните причини:

1. Вече има същестуващ стандарт ISO26300 наречен Open Document Format (ODF): наличието на втори стандарт ще създаде разходи, объркване и несигурност за гражданите, бизнеса и в административния сектор;
2. Не съществува реална имплементация на OOXML доказваща надеждността на спецификацията: в Microsoft Office 2007 се използва специална версия на OOXML, но не могат да се създават файлове с формат спазващ OOXML спецификацията;
3. Спецификацията е непълна. Например липсва информация как да се приложи autoSpaceLikeWord95¹ и useWord97LineBreakRules²
4. Повече от 10% от примерите в предложената спецификация не могат да бъдат ретифицирани като стандартен XML;
5. Не е гарантирано, че всеки може да напише софтуер, имплементиращ частично или пълно OOXML спецификацията, без да бъде подведен под отговорност за нарушаване на патенти или неплатени лицензионни такси от Microsoft;
6. Предложената спецификация противоречи на други ISO стандарти. Например ISO 8601 (Представяне на дати и часове), ISO 639 (Представяне на имена и езици) и ISO/IEC 10118-3 (Криптографски хеш фунцкии);
7. Съществува дефект във файловия формат за електронни таблици, който не позволява въвеждане на дати преди 1900-та година: тези дефекти касаят както OOXML спецификацията, така и следните версии на Microsoft Excel 2000, XP, 2003 и 2007.
8. Предложената спецификация не е създадена вземайки под вниамие опита и експертната оценка на всички заинтересувани страни (като например производители, търговци, потрбители и контролни органи), а самостоятелно от Microsoft.

NO to the Microsoft Office format as an ISO standard

I ask the national members of ISO to vote “NO” in the ballot of ISO DIS 29500 (Office OpenXML or OOXML format) for the following reasons:

1. There is already a standard ISO26300 named Open Document Format (ODF): a dual standard adds costs, uncertainty and confusion to industry, government and citizens;
2. There is no provable implementation of the OOXML specification: Microsoft Office 2007 produces a special version of OOXML, not a file format which complies with the OOXML specification;
3. There is information missing from the specification document, for example how to do a autoSpaceLikeWord95 or useWord97LineBreakRules;
4. More than 10% of the examples mentioned in the proposed standard do not validate as XML;
5. There is no guarantee that anybody can write software that fully or partially implements the OOXML specification without being liable to patent lawsuits or patent license fees by Microsoft;
6. This format conflicts with existing ISO standards, such as ISO 8601 (Representation of dates and times), ISO 639 (Codes for the Representation of Names and Languages) or ISO/IEC 10118-3 (cryptographic hash);
7. There is a bug in the spreadsheet file format which forbids any date before the year 1900: such bugs affect the OOXML specification as well as software applications like Microsoft Excel 2000, XP, 2003 and 2007.
8. This standard proposal was not created by bringing together the experience and expertise of all interested parties (such as the producers, sellers, buyers, users and regulators), but by Microsoft alone.

Използвайте Linux , използвайте Open office и Koffice.

Linux дистрибуциите имат преводи на Български , а и Open office също – защо да плащате или да крадете програми като можете да използвате безплатни такива. Като единственото което се изискава от Вас е да си ги свалите – безплатно от страниците на програмите? Нищо повече а това че било за хора които разбирали много и т.н вече не важи инсталациите на Ubuntu , Fedora , Debian … са направени за всеки който не може да се справи с леснички графични инсталатори.

При желание може да подопомагате в разработване , превод или нещо друго което може да се търси… всичко е за НАС и от НАС !

En este artículo se plantea que, para una persona de izquierda, es inaceptable votar por la Concertación, pues ésta es cómplice de la Alianza al mantener el sistema neoliberal implantado a la fuerza durante la dictadura de la derecha y Pinochet.

El autor además afirma que el Juntos Podemos, al establecer un pacto con la Concertación y escoger a sus candidatos sin consultar a las bases, tampoco merece el voto de los izquierdistas, por lo que recomienda votar nulo.

Si bien uno puede no compartir esta conclusión y escoger votar por el mal menor, en este caso el Juntos Podemos, vale la pena leer dicho artículo si se tiene interés por cambiar el sistema neoliberal que nos rige.

http://jpangamarca.wordpress.com

Estamos a pocos días de una votación de los miembros de la ISO para aprobar un estándar de formato de documentos ofimáticos, OOXML (ISO DIS 29500), tecnología desarrollada por Microsoft, el 29 de marzo de 2008. Este nuevo “estándar” será sometido a votación por parte de los representantes de los países que tienen voto en ISO/IEC, y nuestro país es miembro “P” (principal), es decir, que tiene voto decisivo en la aprobación. Tengo una fuerte posición frente a esta decisión, y es mi deseo, como el de mucha gente alrededor del mundo, que este estándar no sea aprobado. Y no es que sea un capricho, a continuación hago un extracto de las razones por las que este formato no debe ser aprobado.

OOXML.info, en su página lista tres razones principales:

No es abierto: Para que un formato pueda ser considerado abierto, ha de estar libre de regalía o condición alguna por patentes, y no puede ser controlado por una única empresa (…que además en este caso cuenta con un amplio historial de amenazas a sus competidores mediante patentes de software). Por otro lado, el formato en cuestión debe ser multiplataforma por naturaleza. Office OpenXML no cumple ninguna de esas condiciones.

No es estándar: Un estándar debe estar totalmente documentado públicamente. Además, su proceso de estandarización (ECMA) debería haber garantizado que todas las patentes de los proponentes del mismo fueran desveladas y licenciadas como mínimo en términos RAND. Finalmente, es necesario que una propuesta de estándar ISO cumpla y no contradiga los estándares ISO ya preexistentes para no obligar a “reinventar la rueda”. Office OpenXML no cumple ninguna de esas condiciones.

No es XML: Para que un formato de representación de información pueda ser considerado XML, éste debe plasmar íntegramente dicha información en estructuras XML. Para que algo se denomine XML no basta con que que simplemente utilice etiquetas XML cuando en ellas guarda información en formatos binarios, con códigos de control e incluso dependiente de plataformas concretas. En resumen, debe validar el estándar XML. Office OpenXML no cumple estas condiciones.

NOOOXML.org también se suma a esta lucha, es una página en la que se puede firmar digitamente en rechazo a OOXML, y se puede encontrar material técnico y un historial de la lucha en contra de este formato y de las reuniones de la ISO que ya se han dado con respecto a la aprobación. En dicha página se exponen la siguientes razones:

1. Ya hay un estándar, ISO 26300, llamado Open Document Format (ODF): un doble estándar supondrá incertidumbre, confusión y un coste añadido para la industria, gobiernos y ciudadanos;
2. No hay ninguna implementación de referencia de la especificación de OOXML: Microsoft Office 2007 produce una versión especial de OOXML que no cumple con la especificación de OOXML propuesta en ISO;
3. En el documento de especificación falta información como, por ejemplo, cómo implementar un “autoSpaceLikeWord95” o un “useWord97LineBreakRules”;
4. Más del 10% de los ejemplos de su especificación no validan la conformidad con XML;
5. No existe garantía alguna para que cualquiera pueda implementar parcial o totalmente la especificación de OOXML sin arriesgarse a que Microsoft le exija daños y perjuicios por infracción de patentes o el pago de licencias de patentes;
6. Esta propuesta de estándar entra en conflicto con otros estándares ISO, como ISO 8601 (representación de fechas y tiempos), ISO 639 (códigos de representación de nombre e idiomas) o ISO/IEC 10118-3 (funciones hash de criptografía);
7. Hay un error en la especificación del fichero de formatos de hoja de cálculo que impide introducir cualquier fecha previa al año 1900. Esto es un error que se arrastra desde las obsoletas versiones de 16 bits de la aplicación MS-Office;
8. Esta propuesta de estándar no ha sido creada aunando la experiencia y mejores prácticas de todas las partes interesadas (tales como productores, distribuidores, consumidores, usuarios y reguladores), sino por Microsoft en solitario.

NOOOXML.org, en las últimas fechas ha expuesto 20+1 buenas razones para rechazar a OOXML como estándar ISO. De dicha lista expongo las que me parecen más importantes:

• El objetivo de OOXML en ISO es minar la adopción de un estándar ISO ya existente: El evangelista OOXML Mahugh explicó: “Cuando ODF se convirtió en estándar ISO, Microsoft tuvo que reaccionar rápidamente dado que ciertos gobiernos procuran políticas que prefieren estándares ISO. Microsoft, por lo tanto, tenía que apresurar este estándar. ¡Es una simple cuestión de intereses comerciales!”

Como siempre, Microsoft trata de dominar y monopolizar el mercado.

• El texto no está conforme a las reglas para la estructura y borradores de estándares internacionales: El texto es heterogéneo, sin convenciones de denominación, y en muchos casos un mismo término tiene varias definiciones.

• Microsoft reinventa la rueda: No se basa en el uso de estándares maduros existentes, sino que inventa sus propios procedimientos, argumentando ridículamente que no se puede extender los lenguajes XML existentes para sus propósitos, cuando XML por definición es extensible (eXtensible Markup Language).

• OOXML requiere material oculto y con copyright de Microsoft, material que no se ha liberado: Un estándar debe ser abierto. No se podrá hacer implementar de OOXML sin tener que pagar licencias por el uso de dichos materiales.

• El mercado no puede depender de estándares ISO con errores de cálculo: Las fórmulas de hojas de cálculo todavía dan resultados erróneos, por ejemplo la función FLOOR que tiene imprecisiones con números negativos. Es un problema de debe ser cuidadosamente estudiado. Esto es particularmente grave. Las finanzas de muchas empresas y cálculos de variado tipo se llevan a cabo en hojas OOXML de Office 2007. ¿Se puede admitir ese tipo de errores? (recuerden la operación maldita en Excel 2007…)

• La especificación del estándar está escrita en 6000 páginas, lo cual es un exceso para un estándar. Y además, es un infierno buscar algo en la especificación.

Varias grandes compañías como Oracle, IBM, Google y Red Hat expresan su rechazo a la aprobación de este estándar, y vale destacar que ni siquiera se molestan en mencionar la corrupción que rodea a OOXML, sino que se enfocan en los aspectos técnicos. Textualmente, lo dice una cita de Rob Wier de IBM en The Disharmony of OOXML:

“I sometimes hear it said that OOXML, or ODF for that matter, are simply XML serializations of particular applications’ native representations. This is said, seemingly, in an attempt to justify quirkiness or outright infelicitous file format representations. “We had not choice. Office 97 did it that way, so OOXML must as well”. This variety of technological determinism indicates poor engineering judgement, laziness or both.

An easy counter-example is HTML. Does HTML reflect the internals of NCSA Mosiac? Does it represent the internals of Netscape Navigator? Firefox? Opera? Safari? Are any faults in HTML justified by what a single browser does internally? Applications should follow standards, not the other way around.

[…]

What is the engineering justification for this [OOXML] horror? I have no doubt that this accurately reflects the internals of Microsoft Office, and shows how these three applications have been developed by three different isolated teams. But is this a suitable foundation for an International Standard?”

“A veces oigo que OOXMl, u ODF ya que lo mencionan, son simplemente serializaciones XML de representaciones nativas de aplicaciones particulares. Eso se dice, aparentemente, como un intento de justificar la arbitrariedad o las representaciones de archivo indiscutiblemente no aptas. “No tuvimos elección. Office 97 lo hizo de esa forma, así también como OOXML”. Esta variedad de determismo tecnológico indica un pobre juicio de ingeniería, pereza, o ambas cosas.

Un fácil contraejemplo es HTML. ¿HTML refleja la estructura interna de NCSA Mosaic? ¿Representa la estructura interna de Netscape? ¿Firefox? ¿Opera? ¿Safari? ¿Son los defectos de HTML justificados por lo que un solo navegador hace internamente? Las aplicaciones deben seguir los estándares, no al revés.

[...]

¿Cuál es la explicación de ingeniería para el horror OOXML? No tengo duda de que refleja con precisión la estructura interna de Microsoft Office, y muestra cómo estas tres aplicaciones (Word, Excel y Powerpoint) se han desarrollado por tres equipos diferentes y aislados. ¿Pero, es eso una cimiento apropiado para un estándar internacional?”

Para terminar, es inconcebible que se pretenda obtener una certificación como estándar para una tecnología tan mal diseñada y con problemas no sólo técnicos sino de patentes y copyright.

¿Qué podemos hacer?

• Como informáticos ecuatorianos, rechazar OOXML y escribir a INEN para evitar un voto positivo a una tecnología mediocre. Información de contacto en este link, recordando mencionar los recursos en que nos basamos para expresar nuestra opinión.
• No sé cuánta utilidad pueda tener esta acción, pero podemos firmar en contra de OOXML en http://www.noooxml.org/petition-es.
• Suscribirnos a la lista de correo de INEN con respecto a OOXML: http://mail.inen.gov.ec/mailman/listinfo/openxml
• ¡Rezar! Rezar porque no se logre comprar conciencias en la reunión de la ISO…

Fuentes:

• NoOOXML: OOXML is not ready to be an ISO standard: http://www.noooxml.org/start
  20 Good Reasons to Dissasprove OOXML: http://www.noooxml.org/open:rejectooxmlnow
• Dile NO al formato de Microsoft Office como estándar ISO: http://www.noooxml.org/petition-es
• OpenXML no debe ser ISO 29500 – ECUADOR => NO (95 coms.):: http://www.openxml.info/index.php?option=com_content&task=category&sectionid=5&id=12&Itemid=24
• Página de Información de Openxml INEN : http://mail.inen.gov.ec/mailman/listinfo/openxml
• Boycott Novell » OOXML Against ODF a Case of Microsoft Against the Rest of the Industry:: http://boycottnovell.com/2008/03/14/ms-spec-vs-industry-standard/
• Red Hat Opposes OOXML: http://www.press.redhat.com/2008/03/13/red-hat-opposes-ooxml/
• Unresolved Technical Concerns in DIS http://odfalliance.org/resources/Oracle%20Technical%20Concerns%20DIS29500.pdf
• Fun With Microsoft OOXML: http://www.kdedevelopers.org/node/3322

Если бы на тему “войны форматов” ODF и OOXML было написано в 100 раз меньше, мир бы только выиграл.

Одна из смешных заметок на NoOOXML: открытое письмо в ISO по поводу возможного нарушения патентов третьей фирмы в проекте стандарта OOXML.

В основе письма — новостное сообщение двухлетней давности о некотором тролле по имени Scientigo, который заявил о нарушении своих патентов в XML и о готовности собирать деньги за свою “интеллектуальную собственность”. На этом, вроде бы, все закончилось.

NoOOXML эту сомнительную новость поднял, обтрусил пыль и выставил в качестве очередной страшилки против Microsoft. Мол, OOXML не стоит принимать потому, что эта спецификация нарушает патенты третьих лиц. О том, что заявление Scientigo не в меньшей степени касается ODF, а также любой другой спецификации, использующей XML, никто, разумеется, не задумался.

Вообще, само название ресурсов, вроде NoOOXML и BoycottNovell не вызывает доверия. Создается ощущение, что среди людей, пишущих на тему свободного ПО, доля отвечающих за свои слова постоянно снижается, увы.