[mamcx]

El que el formato sea privativo no es para nada el verdadero problema - es un problema tangencial?, si -. Oracle y Sql Server tienen formatos privados y eso para nada impide que sea de facil y dificil lectura.

Mi trabajo en http://www.elmalabarista.com ha sido en parte el de interfazar sistemas. De todo tipo (sql, textos, apis, diferentes motores sql, diferentes lenguajes y plataformas) y el que el formato interno del programa sea o no propietario no es el factor determinante en que sea facil o dificil de leerlo por medios externos.

La razon ppal es esta:

Excel es un programa de usuario/GUI

La funcionalidad de ser de facil "exportacion" es un añadido posterior. Un hack. Como todo programa que se le hackea esta funcionalidad aposteriori la cosa queda floja (empezando porque el codigo original de la mayoria de las GUI esta mezclado y requiere esfuerzo aislar la funcionalidad de parseo de datos de todo lo demas).

Una parte que no se puede obviar es que es un program de GUI:

Es por eso que MS advierte:

http://support.microsoft.com/kb/257757

Actualmente Microsoft no recomienda ni proporciona soporte técnico para la automatización de las aplicaciones de Microsoft Office desde una aplicación o componente cliente desatendido no interactivo (como ASP, DCOM y servicios de NT), ya que Office puede mostrar un comportamiento inestable y quedar interrumpido al ejecutarse en este entorno.

Al correr como un proceso de usuario y no ser un programa cliente/servidor, el cargar excel es cargar todo excel. Y solo excel entiende a la perfección el formato de excel. Y cualquier otro programa que trate de reversar ese formato va a tener líos. Ademas, ese formato es un formato de *cliente*, no esta hecho para ser accesado de forma simultánea.

El que sea cerrado es, en mi opinión, una afirmación que no se debería de intentar hacer que Excel funcione como una BD. NO LO ES.

Aquí es donde la diatriba de lo privativo sale a relucir. Que es cerrado. Eso es tangencial al problema -porque igual el hecho ineludible es que excel es un programa de usuario, monolítico-. Quien haya hecho un programa monousuario sabra que aun dando la especificacion perfecta de ese formato de archivo a otro programador *sabe* que ese otro programador no podra alcanzar 100% de compatibilidad con ese formato, porque ese formato esta diseñado para andar al ritmo de la app - por ejemplo, de un momento a otro, ese formato debe permitir embeder una imagen y como se *ve* la imagen esta amarrado a la implementación de el GUI-.

Esto es el problema #1. Excel es un programa para ser usado, y entendido, por personas aleatorias. No por maquinas aleatoria. Todo programa que tenga el estilo http://es.wikipedia.org/wiki/WYSIWYG es inherentemente complicadisimo de parsear.

Y eso, que el hecho de que Excel pueda ser usado como formato de intercambio es algo que a MS le conviene. Y es por eso que el nuevo formato, es un intento de hacerlo mas facil:

http://en.wikipedia.org/wiki/Microso...ML_Spreadsheet

Y aun asi, anque el formato es texto, sigue siendo un lio, porque?:

----
Un ejemplo notable, y eso que es un formato estandar, abierto, de texto y todo eso, es HTML. Pasear HTML es de lo mas jodido del mundo. Porque? Porque el HTML lo escriben personas. Eso hace que sea posible tener una gigantesca cantidad de HTML dificil de parsear:

http://stackoverflow.com/questions/7...tml-with-a-reg
http://www.codinghorror.com/blog/200...-shopping.html

Es posible que alguien conteste que es mentira: Parsear html es facil!. Eso es porque a)No sabe de lo que habla b) Realmente no esta en el negocio de parsear CUALQUIER html, como ocurre con un webcrawler c) Quizas ha olvidado que los navegadores NO ESTAN DE ACUERDO EN COMO LEER HTML! y por eso tiene diversos incompatibilidades, a pesar de que el html esta estandarizado.

Si se sigue creyendo que el problema es tan simple como lo de abierto, cerrado, libre, open source, muy facil de demostralo. Ir a

http://www.whatwg.org/specs/web-apps...ork/multipage/

Y crearle un cliente (navegador) que lo lea.

A ver que tan facil le parece.

Un razon secundaria y derivada de lo anterior:

Excel no tiene una estructura de datos de facil lectura.

Osea, no tiene un esquema. Es de libre creacion. Y de libre deformacion!

Por ejemplo, en los motores SQL es muy facil hacer introspeccion de datos (se puede usar un SQL para traer la estructura y definicion de las tablas) y los tipos de datos estan marcados y definidos.

Excel, por el contrario, no tiene nada de eso -osea a un nivel de "facil"-. Es como cojer un archivo de texto que alguien escribio de cualquier manera sin pensar en declararle una estructura.

Es posible que ingenuamente se piense que es culpa de MS (por lo malvado que es y todo eso), pero piensen un poco en lo que implicaria *hacer* un formato de hoja de calculo que sea facil de parsear por maquina - o similarmente, como le puede hacer un programador de MS en hacer lo mismo para Excel, aun teniendo código fuente de excel y todo eso-.

Realmente, pienselo un poco:

Un usuario le puede meter una imagen en medio de los datos de una tabla, la cual puede tener datos de forma arbitraria, copy-pasteada de otros sistemas, incompleta y para nada estructurada.

Ahora digamos que quiero extraer esos datos. Como le hago?

Es una tarea BIEN difícil. El que solo Excel sea el programa 100% capaz de leerse a si mismo no solo es una cuestion de lo maldadoso que es MS, es un asunto de limitaciones reales y practicas del problema en cuestion.

Para los programadores que solo saben de hablar con bonitas BD relacionales y que solo hacen interfaces CRUD quizas no le vean el lio que es hacer un programa de estas características.

----

Un maxima sobre este problema se deriva del principio de la robustez:

http://en.wikipedia.org/wiki/Robustness_principle

Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, liberal in what you accept").

Formatos como excel, word, html son MUY liberales en cuanto a lo que aceptan. Aceptan basura y hacen esfuerzo absurdos en interpretar lo que esa basura significa.

Eso los convierte en inherentemente liosos de entender.

---------
Otro ejemplo del mismo tema (con formato texto, libre y open source):

http://search.cpan.org/~adamk/PPI-1.215/lib/PPI.pm

The ability to read, and manipulate Perl (the language) programmatically other than with perl (the application) was one that caused difficulty for a long time.

The cause of this problem was Perl's complex and dynamic grammar. Although there is typically not a huge diversity in the grammar of most Perl code, certain issues cause large problems when it comes to parsing.

Indeed, quite early in Perl's history Tom Christenson introduced the Perl community to the quote "Nothing but perl can parse Perl", or as it is more often stated now as a truism:

"Only perl can parse Perl"

Ven? Solo el program cliente (perl) puede interpretar correctamente su estructura (perl).

Esto es el porque convertir el codigo fuente de un lenguaje a otro es lioso.
------------

Ahora que se tiene los ejemplos y el ppio de ingeniera el cual demuestra que intentar que un cliente externo sea 100% compatible contra el cliente "nativo" es fundamentalmente imposible, es donde hay que pasar a como se arregla el problema.

Lo que sucede a menudo, es simplemente aceptar que interfazar datos e intenciones entre sistemas es una tarea liosa y destinada a fracasar si se quiere la perfección. Así que simplemente, se hace el mejor esfuerzo posible y punto - Eso es lo que hace un navegador, y 300 millones de dolares anuales-

Lo ideal, es que si hay un programa que fundamentalmente esta incapacitado para trasmitir de forma agnóstica sus datos a otros programas, es intermediar con un formato o sistema alterno que no sufra esas deficiencias.

Por eso es que si se va a pasar datos a excel, es preferible usar CSV, XML, conexión directa a una BD, etc.

Lo segundo, es dejar que sea excel quien lea excel, y hacer la exportación desde un plugin instalado dentro del mismo excel.

Osea, en general, hay un sistema que realmente esta diseñado para ser leído e interpretado por múltiples sistemas (ej: Una BD) y este, en contra del principio de la robustez, es tan estricto en lo que lee como en lo que envía, y lo menos ambiguo posible, y luego eso datos son "renderizados" en un programa cliente (como excel).