Fabianadas

La versión en desarrollo de Internet Explorer 8 ya cumple el Acid2, el caso de prueba creado por el Web Standards Project para comprobar el cumplimiento de los estándares HTML y CSS 2.0 por parte del navegador (blog oficial). Actualmente, Opera 9 y Safari ya lo cumplen, mientras que Firefox 2 todavía no (Firefox 3 beta sí que lo hace).

El problema para Microsoft y el equipo de desarrollo de Internet Explorer 8 es seguir apostando por la compatibilidad hacia atrás con las páginas no estándares desarrolladas para funcionar con Explorer 5 o 6. Una decisión que si bien tiene su cierta justificación (un navegador para la web que existe), va a continuar perjudicándoles complicando sobremanera el desarrollo de su propio software y retrasando la llegada a un escenario en el que todos (desarrolladores, navegadores) apuesten por una web realmente interoperable e independiente de la plataforma con que acceda el usuario.

Por cierto, una noticia muy oportuna tras el anuncio de demanda de Opera por no cumplir los estándares.

También lo ha comentado aNieto2K.

Leer el post completo »

Demanda de Opera contra Microsoft ante la Unión Europea por no seguir los estándares en Internet Explorer y por integrarlo en Windows. El segundo argumento es de sobras conocido, es el mismo por el que la UE condenó a la empresa de Redmon a una fuerte multa y a sacar Media Player de Windows, además de causarles problemas en Estados Unidos por temas de monopolio.

Lo verdaderamente interesante está en la acusación que ha hecho Opera: Microsoft sabotea los estándares forzando la incompatibilidad del navegador dominante en la red, Internet Explorer, y por tanto perjudicando a quienes si los siguen, que observan como los creadores de webs optimizan sus páginas para el navegador de Microsoft y no funcionan correctamente. Los detalles, en la nota de prensa. Lo que Opera solicita a la Unión Europea es que fuerce a Microsoft a sacar Explorer de Windows (algo que dada lo integrado que está no se antoja muy sencilla, aunque se conformarían con que ofreciesen otros navegadores preinstalados) y que obligue a Microsoft a seguir los estándares web.

Uso de estándares abiertos por imperativo legal para asegurar la interoperabilidad. ¿Qué puede argumentar Microsoft en su defensa? Que hay un factor importante a la hora de exigirlos en un navegador: la compatibilidad con la web que ya está hecha. Y no sólo me refiero a páginas para usuarios “de consumo”, hay mucha intranet corporativa web que es compatible con versiones antiguas de Explorer… es un mal que se lleva arrastrando desde hace mucho y “cortar por lo sano” es complicado. Es un argumento aceptable, pero cuando se saca una nueva versión como Internet Explorer 7 existe tiempo suficiente mientras es adoptado para que las empresas retoquen sus páginas y se adapten que funcionen en todos los navegadores.

En todo caso, vamos a tener caso “Opera contra Microsoft para rato”.

Más información en R/W.

Leer el post completo »

Microsoft lanza FeedSync, un estándar para la sincronización de datos vía feeds que extiende el formato RSS y que anteriormente era conocido como SSE. Antes de que empecemos a preocuparnos (Microsoft y los estándares, ya saben), comentar que la especificación de FeedSync está bajo Creative Commons permitiendo uso (comercial incluso), modificaciones o construir encima, como puede leerse en la página oficial del proyecto.

La idea detrás de FeedSync es la de poder editar la información desde el lector de RSS (que deberá ser compatible con el estándar) y que estos cambios queden reflejados en el servidor. Con ello tendríamos que, con un sólo cliente, podríamos modificar citas del calendario, entradas en el blog, la información sobre una foto o un contacto.. cualquier elemento susceptible de ser compartido con RSS y con la puerta abierta a modificaciones por parte de un grupo de forma asíncrona. Nada que no pueda hacer una aplicación web, claro, pero con la ventaja de ser un estándar bastante sencillo, adoptable por cualquiera y que extiende la experiencia que ya tenemos con los canales RSS.

Leer el post completo »

Uno de esos estándares raros de los que a veces comentamos por aquí y que apuntan a una visión nueva de la web. Hablo del APML o Attention Profiling Markup Language, un proyecto de estándar de formato de datos en XML para almacenar el “perfil de atención de un usuario”. Estamos hablando de cómo almacenar la información de lo que valoramos en distintas webs, los sitios que uno marca como favoritos, los grupos y canciones que selecciono en Last.fm, los productos que apunto en mi wishlist, etc… AMPL aspira a ser un formato que permita almacenar ese tipo de información y, como ya sucede con OMPL en los agregadores web, sea utilizado para importar y exportar los datos del usuario.

La idea es poder pasar de un servicio de valoraciones o de marcados o de muchas funcionalidades (caso de Facebook) a cualquier otro sin tener que empezar de cero, sin tener que a guardar/almacenar/seleccionar los distintos items de nuevo. Claro que esto podría hacerse vía API del servicio origen, pero esto requeriría programar una solución para cada importación/exportación; AMPL sería una forma de establecer un estándar único, con lo que se desarrollaría sólo una función de importar/exportar y entroncando con una visión de redes sociales abiertas, en la que habría que emparejarlo a OpenId y Oauth.

Este tipo de información es probablemente la más valiosa que tienen los distintos servicios, siempre prestos a poner barreras de salida a sus usuarios. Perder todas las valoraciones explícitas e implícitas es una de las más importantes, por lo que no es de extrañar no ver a los grandes de la industria detrás de AMPL, aunque sí estén Bloglines o Digg.

Sitio oficial: Apml. En castellano han hablado del tema Vivaestudio y xKortazar.

Leer el post completo »

Android me parece lo suficientemente interesante como para no dejarlo en un simple anuncio, merece la pena echar un vistazo un poco más a fondo a lo que ha propuesto Google. Un aspecto muy interesante de esta Open Handset Alliance es la licencia con la que planean publicar el sistema operativo que están creando, la Apache Software License (ASL).

¿Por qué la licencia Apache y no GPL? Pues básicamente porque la primera permitirá a las operadoras modificar a su gusto la plataforma Android, añadir nuevas funcionalidades y no tener que compartir el código ni permitir su uso por terceros. De esta manera se entiende que algunas operadoras y fabricantes poco caracterizados por su apertura, se hayan sumado a Android, podrán modificar la plataforma y hacer productos derivados sin la obligación de compartir estos trabajos. Eso sí, cualquiera podrá descargar, acceder al código fuente, modificar y redistribuir Android, pero no se dará el “ciclo virtuoso” de que todo aporte vuelva a la comunidad para enriquecer el proyecto. Se trata de un ejemplo de “tivocización” contra el que lucha la GPL3. Para apuestas en este sentido, merece la pena echarle un vistazo a Open Moko.

Más información: licencia Apache, Ars Technica.

Leer el post completo »

Para valorar en su justa medida OpenSocial, creo que hace falta echar un vistazo a Oauth, un estándar abierto cuyo último borrador fue lanzada hace apenas un mes. Oauth define un mecanismo para que una aplicación web (cliente) pueda acceder a la información de un usuario en otra (proveedor) sin tener que informar a la primera del usuario y contraseña.

Imaginemos que queremos programar una aplicación tipo “página de inicio para el usuario”, en la que este pueda añadir sus fotos de Flickr. Para ello utilizaremos el API de Flickr, le pediremos el nombre de usuario y contraseña al usuario y armaremos dicha página. En este tipo de situaciones es en el que Oauth tiene sentido, comunicaciones entre aplicaciones web en la que hay acceso a datos de usuario. La idea es que la aplicación cliente (en este ejemplo nuestra página de inicio) no tenga acceso al nombre de usuario y contraseña del usuario. Dicho de otro modo, Oauth es una metodología para identificación mediante APIs genérica y de implementación gratuita. Si estas cansado de servicios que te piden el usuario de Gmail o Hotmail para proveerte de tal o cual funcionalidad, ya puedes ir viendo por donde puede estar la utilidad de un protocolo como Oauth.

Por supuesto ya hay un montón de estándares cerrados que hacen esto, por ejemplo Google AuthSub o las APIs de Flickr y Facebook, pero la idea tras Oauth es unificar en un estándar abierto de forma que este tipo de comunicaciones entre aplicaciones web (bueno, el cliente puede ser web o de escritorio) no se articulen mediante protocolos propietarios.

Inmediatamente uno piensa en OpenId, pero Oauth no sustituye este estándar para identificación de usuarios, sino que lo complementa. De hecho, los usuarios nunca “ven” nada relacionado con Oauth, situado en el nivel de comunicación entre aplicaciones. De hecho, gran parte de la gracia de Oauth es que el usuario controle a qué datos acceden terceras aplicaciones. Siguiendo con el ejemplo de Flickr, se podría establecer qué tipo de fotos sí y cuáles no desde el servicio proveedor y los clientes no podría obtener nada más.

Como dato curioso, detrás de Oauth están Pownce, Twitter, SixApart, Jaiku, Flickr, Ma.gnolia y Google entre otros, aunque este último parece que no lo soporta en OpenSocial de entrada. Entiendo que el motivo es que no hay una versión final del estándar todavía.

Más información en su sitio oficial, que tiene blog. En español hay referencias en eConectados y La cofa.

Leer el post completo »

Habrá Silverlight en Linux y será el ya comentado por aquí Moonlight. Eso sí, el trabajo a Microsoft se lo hará Novell, con la que ha llegado a un acuerdo para darle acceso a las especificaciones, los test oficiales y permitirle el uso de los codecs que utiliza Silverlight. Con todo esto, Novell se compromete a implmentar Silverlight 1.0 y 1.1 para las distintas distribuciones, anunciando versiones para Konqueror, Opera y Firefox (éste primero, el resto, más adelante).

El anuncio del acuerdo con Novell (los detalles en el blog de Miguel de Icaza) coincide con el anuncio de la salida de Silverlight 1.0 (Scott Gu). La versión 1.1 todavía tendrá que esperar un tiempo, siendo la más interesante puesto que es la que incluye una versión multiplataforma de .Net.

Creo que el movimiento de Microsoft es interesante por muchos aspectos. Por un lado es el reconocimiento de que no puedes plantear una tecnología web excluyente, sin que sea realmente multiplataforma. Por otro lado, la alianza con Novell se hace cada vez más profunda, más allá incluso de sus acuerdos sobre patentes y Suse. Por mucho que uno recele de los runtimes propietarios (Flash incluido), no dejo de sorprenderme de Microsoft dando soporte a una versión para Linux de una de sus tecnologías punta.

En todo caso, para que Silverlight pueda llegar a competir en serio con Flash, Microsoft necesita un Youtube (¿podría ser Live Station?), una aplicación web de consumo masivo que haga que los usuarios quieran instalarse los plug-ins. El otro camino es Windows Update, claro.

Dejo un enlace a una demo de Halo3 hecha en Silverlight, por si alguien quiere comprobar la calidad de la cosa con el streaming de vídeo.

Leer el post completo »

Aunque no hay anuncio oficial (sí que lo hay ya, está en iso), se ha filtrado que ISO ha rechazado la aprobación por la vía rápida del estándar OOXML de Microsof (Pc World, Barrapunto).

Ahora queda que la propuesta de convertir a Office Open XML como estándar ISO tenga que ser revisada para tener en vuenta las objeciones de los que han votado negativamente. El restultado es que OOXML no será ISO este año, pero aún puede llegar a serlo durante el año que viene. A Microsoft le queda la patata de estudiar hasta que punto soportará OpenDocument (de momento tiene un plug-in) con vistas a no perder mercado en las administraciones públicas, cada vez más concienciadas en el uso de estándares abiertos.

Eso sí, en su nota de prensa, Microsoft prefiere ver el vaso medio lleno.

Relacionado: Office Open XML como estándar ISO.

Leer el post completo »

Cuando hace un par de años Microsoft presentó Office Open XML como estándar (OOXML) ya lo recibimos con la dosis necesaria de escepticismo. No porque no hubiese avisado (meses antes había publicado los esquemas de los ficheros de Word), sino porque la conversión de quien por historia ha conseguido imponer sus estándares cerrados siempre es difícil de creer. El hecho de atesorar patentes sobre el uso de XML en los procesadores de texto tampoco ayudaba, por más que Microsoft haya “prometido” no utilizar las demandas que posee sobre OOXML.

Y es que desde los años 90 en los que Microsoft Office se convirtió en el estándar de facto de la ofimática ha cambiado alguna cosa. La principal es que la concienciación por el uso de estándares abiertos en las administraciones públicas ha crecido gracias a la presión de numerosas asociaciones y de sus competidores, con Sun e IBM a la cabeza. Sin duda el caso paradigmático fue el de Massachusetts, por estar situado en Estados Unidos y por dibujar un escenario aterrador para Microsoft: Office se veía amenazado por no soportar OpenDocument (ODF), el estándar abierto, aunque esto fue subsanado con un plug-in y ganaron el contrato.

Más adelante ODF se vería reforzado siendo elegido estándar ISO. Con este escenario, Microsoft se ha empeñado en convertir a OOXML en un estándar reconocido por las instituciones. Lo consiguieron con ECMA y mañana ISO decide sobre el tema.

La importancia de ello se ejemplica en el caso antes citado de Massachusetts, que después de que ECMA aceptase el formato de Microsoft, decidió admitirlo para su uso en la administración (BetaNews), una auténtica victoria de la compañía de Gates. Con este panorama, conseguir que OOXML sea estándar ISO permitiría presentar a Microsoft Office 2007 como la plataforma para el estándar de iure y compatible hacia atrás, con todos los archivos generados durante los últimos años.

Los argumentos de Microsoft

Más allá de la discusión técnica (sobre el soporte de ficheros binarios) y de patentes (sobre las no cubiertas por la promesa de Microsoft y sobre si Sun e IBM las tiene sobre ODF) que pueden seguir en las referencias al final, me interesan sobre todo dos: una señala que la diversidad de estándares es buena porque estimula la competencia y otra OOXML es superior técnicamente a ODF.

Sobre la primera mi opinión es que, si bien puede tener cierto sentido, el fundamento principal de un estándar en ofimática es que se puedan compartir documentos entre usuarios y aplicaciones. Por más que se pueda programar el soporte de todos (si son realmente abiertos), son útiles si nos ponemos de acuerdo en qué utilizar. La competencia queda desplazada a los clientes de estos estándares y ahí Microsoft está preocupada: aunque Office 2007 es superior a cualquier otra propuesta del mercado, para tareas básicas muchas de las alternativas son más que suficientes.

La supuesta superioridad de OOXML nos lleva al tema de si el estandarizar (congelar una especificación en un momento determinado) va contra la innovación, puesto que durante el proceso de aprobación y la vigencia del nuevo estándar, todos los avances quedan sin aplicar. El argumento se auto-destruye: si se elige OOXML, los avances que por otra parte se hagan no estarán en el estándar. El único modo de conciliar innovación y estandarización es aplicar lo novedoso al estándar vigente.

Y es en este punto en el que creo que está la clave para desear la derrota de OOXML. No tengo motivos para estar seguro que sea “una trampa” de Microsoft para luego iniciar una guerra de patentes (más bien veo eso muy poco verosímil) o que confien en que nadie podrá implementarlo (de hecho Apple con iWork ya ha demostrado que es posible hacerlo en otras plataformas). Sí creo que cuentan con que si se aprueba, serán los únicos en soportar ahora mismo tanto OOXML como ODF (¿irónico, no?) y podrán presentarse como los creadores y especialistas en un estándar ISO. Con ello, mi convencimiento es que ODF debe seguir siendo el único estándar ISO para la ofimática y que el camino para Microsoft es la implementación directa (sin plug-in) del mismo en su suite. Si en realidad se cree estándares abiertos, la apuesta es contribuir y dar soporte al aprobado, no plantear una alternativa al margen de todo y de todos. Mañana veremos en qué queda todo esto.

Más referencias:

• Dans sobre el oscuro affaire sueco. Algo que debería llevar a ISO a replantearse cómo llega un estándar a aprobarse.
• Ati y un monográfico sobre ODF.
• Rofrigo Corral defendiendo la postura de Microsoft.
• NoOOXML recoge todas las criticas a la estandarización.
• El Diablo y las reglas de la votación.
• Maligno ataca a la desinformación sufrida por Microsoft.

Leer el post completo »

“las Administraciones Públicas utilizarán estándares abiertos así como, en su caso y de forma complementaria, estándares que sean de uso generalizado por los ciudadanos…

… los ciudadanos tienen en relación con la utilización de los medios electrónicos en la actividad administrativa, y en los términos previstos en la presente Ley, los siguientes derechos: a elegir las aplicaciones o sistemas para relacionarse con las Administraciones Públicas siempre y cuando utilicen estándares abiertos o, en su caso, aquellos otros que sean de uso generalizado por los ciudadanos.”

La LAECAP se ha convertido en la ley “en su caso”, un método fantásticamente ambiguo para no establecer que las administraciones públicas utilicen estándares abiertos que aseguren que cualquier proveedor puede desarrollar un software que los utilice. El “en su caso” no es sino la puerta abierta para mantener a los ciudadanos y administraciones públicas esclavos de empresas que controlan estándares cerrados.

El argumento de que “todo el mundo usa hoy día el software x y obligar a usar el formato z no soportado por x, causaría muchos problemas” es un “argumento trampa”: nadie impide - por poner un ejemplo - a Microsoft en su Office soportar el formato Open Document, que es el estándar ISO. El tema de los estándares abiertos es esencial para que los ciudadanos tengamos libertad a la hora de elegir el software que queremos utilizar para comunicarnos con la Administración Pública. Quedarse en las medias tintas, como hace esta ley, supone mantener unas dependencias de las que los únicos beneficiados son los fabricantes software que apuestan por los estándares cerrados.

El texto se puede leer en Senado.es

Leer el post completo »