Xnoccio

E3L son las siglas de Environmental Electronic Exchange Language y nace ante la necesidad de establecer un formato estándar de intercambio de datos ambientales entre las distintas comunidades autónomas. Se trata de un proyecto colaborativo, en el que las AA PP implicadas consensúan los flujos de información y los plasman en un lenguaje común con unas reglas definidas y aceptadas por todos. E3L proporciona no sólo las reglas para comunicar plataformas tecnológicas, sino que conforma el primer diccionario electrónico de datos ambientales (metadatos). E3L cubre por ejemplo la presentación telemática de la Memoria Anual de Gestores de residuos, la Declaración Anual de Productores de residuos, los Documentos de Control y Seguimiento de residuos, etc. Para más información sobre este proyecto se pueden visitar los portales del proyecto:

• http://www.e3l.es/
• http://www.eterproject.org/

La Consejería de Medio Ambiente de la Junta de Andalucía ha apostado fuerte por la iniciativa y como resultado de ello confió en VIAVANSI para construir Augi@s, un sistema integral de gestión de residuos pionero al hablar E3L. Augi@s permite completar el ciclo de un documento desde su creación hasta su presentación y firma. El sistema ha sido diseñado para hablar en lenguaje E3L; por ello, el equipo de proyecto, constituido por personal de la Consejería de Medio Ambiente y de VIAVANSI, ha participado en la definición del estándar durante su desarrollo. Esto supone al fin una garantía de futuro para el formato de los datos manejados por Augi@s.La aplicación está diseñada con la máxima flexibilidad posible, externalizando en un API independiente la gestión del formato E3L, permitiendo adaptarse a los cambios del mismo en poco tiempo, o integrar nuevos elementos como los servicios publicados en E3S, que ya se encuentran en fase de pruebas en Augias.Considerando la aceptación del formato E3L a nivel estatal y la posibilidad de exportar dicho formato a otros países de la UE, podemos decir que la plataforma Augi@s se encuentra en una posición privilegiada de cara al futuro y vuelve a demostrar que, en contra de lo que se supone en varios círculos de opinión, Andalucía suele liderar a nivel nacional la innovación en muchos proyectos tecnológicos.

Podemos ver que hace ya unos días se ha publicado una regulación del Esquema Nacional de Interoperabilidad o de forma resumida ENI.

En él se recogen una serie de directrices que pretenden ser un conjunFto de normas o pautas a los que las Administraciones Públicas han de ajustarse con el objetivo de permitir y favorecer  la interoperabilidad entre los distintos sistemas de información dentro de la propia Administración.

Podeis ver una introducción AQUI

Y de forma más extendida en el B.O.E.

Este Real Decreto no abandona una visión distribuida de los diferentes sistemas de información, donde cada Administración puede dar respuesta a determinados problemas que sólo surgen dentro de un ámbito muy concreto. Pero por otro lado puede ser muy útil para evitar la reinvención de la rueda, es decir, de soluciones que pueden ser aplicadas en distintas situaciones, algo muy común a día de hoy quizás por desconocimiento, quizás por “desorganización” dentro de la propia Administración.

Este texto apuesta claramente por una publicación vía electrónica de todos los servicios de la Admón. de forma organizada a través de Inventarios, gestionados por las Administraciones locales pero a su vez que se integren dentro de un Inventario a nivel Nacional, sin olvidar en ningún momento el aspecto Semántico de los diferentes servicios.

Se hace un guiño a favor del uso de estándares abiertos y de herramientas genéricas, pero a su vez, se puntualiza que se puedan usar otros con la finalidad de favorecer el acceso al ciudadano y el no estancamiento tecnológico.

La Firma y Certificados Electrónicos se ha convertido en una herramienta muy útil y funcional, y como no podía ser de otra forma encontramos un amplio apartado dedicado a esto aplicado a la relación entre sistemas consumidores y publicadores de los distintos servicios.

Sobre los Documentos Electrónicos, se hace referencia al almacenamiento y disponibilidad de dicho documento, siempre bajo unas reglas de seguridad sin pasar por alto la famosa LOPD, siguiendo las principios de integridad, autenticidad, confidencialidad, etc. Se habla también de los formatos en que ha de almacenarse los documentos y de la digitalización de los documentos en soporte papel.

Sin duda, vemos que éste es un texto bastante genérico y más que ser una enumeración de normas/estándares concretos, algo que sería cuanto menos utópico si hablamos a nivel nacional,  se trata de una apuesta y declaración de intenciones bastante condundente.

Después de haberle dedicado unos minutos a este texto y cuál sería su implicación a nivel autonómico, más concretamente en Andalucía, sin duda alguna se me viene a la cabeza una palabra: PLATINA. Desde hace algún tiempo la Administración Andaluza ya viene observando la problemática de tener un batiburrillo de servicios muchas veces difícil de conectar entre si y viene apostando por esa plataforma como “anillo único para unirlos a todos”.

Sin duda, la interoperabilidad entre sistemas,  es un tema que quizás al inicio de los tiempos no se veía tan necesario, pero si no hemos abordado ya a día de hoy: ¡vamos tarde!

Nuestro compañero Juan G. Hurtado (experto en css, web semántica, …) ha iniciado un nuevo blog y su intención es empezar desde un XHTML sin estructura ni diseño e ir mostrandonos en “directo” el nacimiento de un blog.

Iteración 0:
http://coloresefimeros.com/2009/07/19/iteracion-00-comenzando/

Iteración 1:
http://coloresefimeros.com/2009/07/22/iteracion-01-el-theme-y-el-xhtml/

Iteración 2:
http://coloresefimeros.com/2009/07/29/iteracion-02-primeros-pasos-con-css/

(El resto de iteraciones en)…
http://coloresefimeros.com/category/iteraciones/

Para los que no le conozcan, nuestro compañero es el de la izquierda:

Dentro del escenario de la web semántica, el estándar del Cool URIs se centra en definir el mecanismo de acceso a recursos basados en URIs, así como concretar el protocolo de negociación para el acceso a dichos recursos.

Este estándar, facilita la interoperabilidad del contenido web en el contexto de la web semántica, indicando como publicar la información sobre los recursos de manera que tanto máquinas como humanos puedan acceder a ella de una forma sencilla.

Para conseguir esto, el estándar define un conjunto de pautas básicas a seguir a la hora de publicar URIs, de este conjunto de pautas, las más interesantes son:

• Las URIs deben ser semánticas, de forma que teniendo sólo las URIs tanto máquinas como personas puedan obtener una descripción del tipo de recurso identificado.
• A una misma URI, las máquinas deben obtener RDF y las personas una visión legible en HTML. De forma más general se recomienda adaptar la respuesta al cliente que solicita el recurso, de forma que los humanos obtengan contenido inteligible por ellos y las máquinas obtengan algun tipo de recurso fácilmente procesable.
• Las URIs no deben ser ambiguas. Hay que distinguir entre documentos web e identificadores de recursos. No se deben utilizar URIs a documentos para identificar recursos reales. Se recomienda usar un mecanismo de resolución que en función de un identificador de recurso (URI) redirija al contenido RDF o al contenido HTML en función del tipo de cliente que solicita el recurso.
• Uso de Hash URIs o 303 URIs para el acceso a recursos parciales (zonas de documentos, o recurso no reales)
  • Hash URIs: Utilizando el símbolo “#” para referenciar fragmentos o partes especiales de una URI. Esta es la opción preferída.

• Uso del estado HTTP 303 para la redirección del usuario al recurso o fragmento indicado.

• Las URIs deben ser simples y fáciles de recordar.
• Las URIs deben ser estables y pensadas para continuar durante años. Por este motivo no deben aparecer extensiones relacionadas con la tecnología (.jsp, .asp, .php, etc… ).

Gracias a OpenSearch podemos publicar un sistema de búsqueda de forma que sistemas externos puedan federarse y realizar búsquedas sobre nuestro sistema. Este mecanismo de integración puede ir más allá, e incluido en las cabeceras de nuestras web permite que Firefox e Internet Explorer ofrezcan la búsqueda directa sobre nuestra web. Para conseguir esto, los únicos pasos a realizar son declarar este servicio en el head de nuestra web y definir el servicio mediante un fichero OpenSearchDescripcion.

• Añadimos en el head de nuestro página web:

    <link rel=“search” href=“http://www.xnoccio.com/site_osd.xml” type=“application/opensearchdescription+xml” title=“Buscar información en Xnoccio”>

• Creamos el fichero site_osd.xml al que hacemos referencia en el link:

<?xml version=”1.0″?>

<OpenSearchDescription xmlns=”http://a9.com/-/spec/opensearch/1.1/”>
<ShortName>Xnoccio (Buscador)</ShortName>
<Description>Busca en todos los artículos publicados en xnoccio</Description>
<Image height=”16″ width=”16″ type=”image/x-icon”>http://www.viavansi.com/opencms/opencms/viavansi/favicon.ico</Image>
<Url type=”text/html” method=”get”template=”http://xnoccio.com?s={searchTerms}”/>
<!–<Url type=”application/x-suggestions+json” method=”GET” template=”http://xnoccio.com?action=opensearch&search=searchTerms}”/>
</OpenSearchDescription>

Con esta mínima modificación conseguiremos que el navegador pueda ofrecer los servicios de búsqueda directamente al usuario de una forma muy sencilla.

He leído en la lista de Accesoweb de Sidar, que el El W3C acaba de publicar una nueva lista de recomendaciones en materia de accesibilidad. Es la WCAG 2.0 (Web Content Accesssibility Guidelines 2.0).

El W3C es la organización de mayor reconocimiento en materia de estándares web. Las especificaciones en esta materia de las administraciones públicas españolas, como la Junta de Andalucía o el Gobierno de España, hacen referencia siempre a las WCAG por lo que las pautas se convierten para nosotros en normas de facto.

Era evidente la necesidad de una revisión profunda de algunas de las pautas. Las indicaciones sobre uso de h1-h6 para identificar encabezados por ejemplo, con un uso más semántico que “topográfico”, es indicativo de esta nueva orientación.

Las nuevas recomendaciones se articulan sobre cuatro patas que debe tener cualquier contenido web:

• Perceptible (por ejemplo a través de alternativas textuales para imágenes, subtítulos para audio, presentación adaptada y contraste de colores);
• Operable (tratando el acceso del teclado, el contraste de colores, la coordinación de la entrada de datos, evitando el control automático y control de la navegación);
• Comprensible (teneniendo en cuenta la legibilidad y predicción del contenido, y la asistencia de introducción de datos); y
• Robusto (por ejemplo, manejando la compatibilidad con las tecnologías asistivas).

De todas maneras, mientras que la normativa con respecto a accesibilidad web no contemple un órgano regulador o una certificación oficial homologada, se seguirán poniendo alegremente en los portales las famosas “A”, “AA”, e incluso “AAA” (que se siguen manteniendo sin introducir la pintoresca A+) como quien tunea su buga con la pegatina de SuperTurbo, sin pasar siquiera los test automáticos, e incautos clientes que se verán deslumbrados con el dorado sello. De risa. O de pena :S

La nota de prensa:
http://www.w3.org/2008/12/wcag20-pressrelease.html

Y la recomendación en
http://www.w3.org/TR/WCAG20/

De forma muy resumida, OpenSearch es una colección de formatos abiertos y estándares desarrollados por A9 (Amazon), que persiguen resolver 2 escenarios principalmente:

• Caso 1: Permitir a una aplicación publicar de una forma estándar resultados de búsqueda; estos resultados pueden ser consumidos posteriormente por una aplicación cliente. Se basa en un metamodelo estandarizado publicado bajo una fuente de sindicación estándar como RSS o Atom. Podemos ver un ejemplo de resultado de búsqueda en formato OpenSearch en esta URL de indeed.com.
• Caso 2: Describir (autodescribir) servicios de búsqueda. Es lo que utiliza por ejemplo Firefox 3 para ofrecernos búsquedas inteligentes.

En este post vamos a describir cómo leer resultados de búsqueda en formato OpenSearch (caso 1). Para el caso 2, recomendamos la lectura de un post de 11870.com que describe a la perfección cómo describir nuestro buscador.

Si nos fijamos en el código fuente de respuesta de la URL comentada de indeed, veremos que en este caso se está devolviendo sobre RSS una información general sobre la búsqueda más un conjunto de resultados de búsqueda (items), los cuales pueden ser incluso geolocalizados.

En Java, este RSS (o Atom) podría ser leído con cualquier intérprete de XML, o mejor con alguna librería específica de este tipo de feeds, como Rome o Apache Abdera, o mejor aún, con librerías específicas para OpenSearch. En nuestro caso, debíamos leer la respuesta del API de 11870.com, dentro de un proyecto en el cual deseábamos proponer establecimientos propuestos por los usuarios que estén cercanos a nuestra localización.

A este respecto, cuando he hecho la búsqueda de librerías Java, personal he tenido una sensación agridulce. Si bien los desarrolladores Java solemos ser unos verdaderos privilegiados en cuanto a lo que se refiere a disposición de API’s, en ciertos casos relacionados con web semántica o API’s de web 2.0 tengo la sensación de que otras arquitecturas de desarrollo como PHP, Python o RoR a veces tienen cierta ventaja. En el caso de Java todo son versiones de incubadora, 0.X, etc.

En el caso de librerías Java, una rápida búsqueda nos llevó a decidirnos entre Rome (Sun) y Apache Abdera, escogiendo este último por disponer de mejores ejemplos de los que partir. Además dentro de los committers de Abdera está el supercrack David Calavera, desarrollador de la omnipresente 11870.com.

A continuación incluiremos unos pequeños recortes de código que muestran como leer la respuesta OpenSearch mediante Abdera. En primer lugar, necesitaremos disponer de las librerías. Para ello (en el caso de Maven) incluiremos estas dependencias en nuestro pom.xml:

<dependency>
<groupId>org.apache.abdera</groupId>
<artifactId>abdera-client</artifactId>
<version>0.4.0-incubating</version>
</dependency>

<dependency>
<groupId>org.apache.abdera</groupId>
<artifactId>abdera-extensions-opensearch</artifactId>
<version>0.4.0-incubating</version>
</dependency>

Para poder resolver estas dependencias incluiremos los repositorio Incubating y Snapshot de Apache dentro de <repositories>:

<repository>
<id>apache-incubating</id>
<name>Apache Incubating Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository/</url>
</repository>
<repository>
<id>apache-snapshots</id>
<name>Apache Snapshot Repository</name>
<url>http://people.apache.org/repo/m2-snapshot-repository/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>

Dado una dirección URL (String urlQuery) donde esté publicada una consulta que responde OpenSearch, podremos invocarla con el siguente código:

Abdera abdera = new Abdera();
Parser parser = abdera.getParser();
URL url = new URL(urlQuery);
Document<Feed> doc = parser.parse(url.openStream(), urlQuery);
Feed feed = doc.getRoot();

Podemos recuperar ciertas propiedades de la respuesta de OpenSearch:

IntegerElement totalResults = feed.getExtension(OpenSearchConstants.TOTAL_RESULTS);
int resultados = totalResults.getValue();

Del mismo modo se pueden recuperar datos como el número de items por página (OpenSearchConstants.ITEMS_PER_PAGE) o el índice inicial de la respuesta, útil cuando hay paginación (OpenSearchConstants.START_INDEX. Es decir, podemos obtener datos OpenSearch del feed mediante feed.getExtension().

A continuación mostramos cómo iterar los items de respuesta del feed:

for (Entry entry : feed.getEntries()) {

    System.out.println(”Title: “+entry.getTitle());
    System.out.println(”Summary: “+entry.getSummary());
    System.out.println(”Id: “+entry.getId().toString());
    System.out.println(”Id: “+entry.getId().toString());

}

También podemos evaluar para cada item (resultado de búsqueda) el valor de extensiones a OpenSearch. Por ejemplo, podemos pretender recuperar los datos de geolocalización en formato GeoRss. Para ello utilizaríamos un código como el que sigue:

QName qnameWhere = new QName(”http://www.georss.org/georss/10″,”where”, “georss”);
Element where = entry.getExtension(qnameWhere);
try {
String geoPos = where.getFirstChild().getFirstChild()
.getText();
String[] posicion = geoPos.split(” “);
if (posicion.length == 2) {

System.out.println(”latitud: “+posicion[0]);
System.out.println(”longitud: “+posicion[1]);
}
} catch (Exception e) {
e.printStackTrace();
}

Es decir, podemos recuperar el valor de un parámetro de una extensión invocando a entry.getExtension, pasando como parámetro un objeto de tipo QName, instanciado como indicamos en el código anterior.

En definitiva, hemos hecho una breve introducción a OpenSearch y mostrado código de ejemplo para interactuar con una respuesta OpenSearch mediante Apache Abdera.

Pocos de nuestros lectores sabrán que dentro de VIAVANSI tenemos a un blogger ex-semi-profesional… Juan G. Hurtado, aka Armonia.

Juan tenía Armonia, un blog muy técnico muy dedicado a la Web y sobre todo a la capa de cliente (estándares), con una cantidad terrible de visitas. Le hizo bastante conocido en la blogosfera 2.0 hispana, le hacían entrevistas, salía en revistas internacionales… Su blog fue su CV y su reclamo para entrar en VIAVANSI. Ahora es el señor Semántico, nuestro crack de capa de cliente y uno de los secretos de que a nuestros clientes les guste la interfaz de nuestras aplicaciones. Sin embargo, por desgracia, un buen día se hartó y dejó de escribir.

Por eso, como opinan otros muchos internautas, señor armonía: ¡vuelva a escribir! *

*Y si escribes en xnoccio, pues mejor :-)

Ayer estuve en una jornada organizada por Avante Formación en la Cartuja sobre Usabilidad. Un evento de autopromoción, vaya, pero con la presencia de Yusef Hassan, un crack de la usabilidad en España. Lo mejor, casi lo único interesante fue lo que él dijo. Y digo “casi” porque hubo una bollería más que decente en el desayuno, y porque Quino Terceño, de Cero4 nos obsequió con esta perla:

“El programador diseña aplicaciones igual que un minero diseña paisajes: cavando zanjas y haciendo montones”

Citaba a Alan Cooper en su libro About Faces 2.0.

Pardiez, qué lucidez.

Otras cosas que me interesaron:

Yusef: diseño centrado en el usuario; modelo que sustituye al de cascada (secuencial e irreversible) por éste otro, conocido como “modelo lavadora”:

Modelo lavadora del diseño centrado en el usuario

Yusef:

• El cliente no es el usuario
• El cliente no es el diseñador
• Nosotros no somos el usuario
• Desde que los ratones tienen ruedecita, no es necesario desviar el foco para hacer scroll, por lo que el contenido no tiene por qué comprimirse en una pantalla

Quino:

• Los errores hay que representarlos contextualmente (nos enseñaba el diseño de un procedimiento extenso, con múltiples páginas y formularios)

Por último, nos metieron con cuña una presentación de Microsoft Expression, para el diseño de interfaces. Para Ethel, la web del futuro es algo así como “Microsoflash 2.0″. Esta chica se ve que no visita mucho el sitio de O’Reilly.
Supuse que eran ellos quienes pagaban los pastelitos y el café, así que fui prudente y no hice preguntas.

Si la decisión de hacer libre un proyecto o librería ya está tomada, aún queda la ardua labor de elegir la licencia que más nos conviene. En nuestro caso concreto, siendo una PYME, la elección ha sido la GPL. Enumero y explico nuestras motivaciones:

- La licencia GPL es vírica por lo que si algún proyecto utiliza el código liberado, éste tendrá que ser a su vez publicado como GPL. Con esto conseguimos por un lado colaborar con la comunidad y por el otro evitar la competencia desleal de otras empresas del sector, que podrían utilizar el código sin proporcionarnos un beneficio recíproco.

- La licencia GPL nos permite liberar el código y a la vez, como titulares del copyright, seguir utilizando éste, si es necesario, en desarrollos no-libres. Incluso nos permite mantener una licencia dual, comercial y libre (el ejemplo más claro lo tenemos en MySQL).

- Hemos descartado licencias tipo BSD, ya que no nos otorga ningún tipo de protección frente al uso del código por terceras empresas. Incluso Microsoft podría incluir parte de vuestro código (Como el caso típico de la implementación de la pila TCP/IP tomada prestada de BSD) :) …

- Otra licencia interesante es la licencia de Apache, pero está más pensada para grupos de proyectos y grandes organizaciones. Estas licencias no son víricas, por lo que son compatibles con cualquier otro proyecto con la única limitación de hay que indicar en los créditos a los autores. Además son licencias muy complejas, más adecuadas para librerías y aplicaciones que se deban integrar con código heterogeneo.

- Usar la GNU GPL exige que todas las versiones mejoradas que se publiquen sean software libre. Con esto evitamos el riesgo de tener que competir con una versión modificada de forma privada de nuestro propio trabajo.

-La LGPL (renombrada a GPL Reducida), es una buena opción, pero nos da menos ventaja por ser autores, ya que al estar pensada inicialmente para librerías, no obliga a que las aplicaciones que hagan uso de éstas, sean a su vez libres.

-La GPL no plantea problemas si utilizamos bibliotecas no GPL, siempre y cuando indiquemos de forma clara su existencia.

-La EUPL, es una apuesta de futuro promovida por la Unión Europea y que tiene previsto adoptar para la liberación de software en las administraciones públicas de Europa. Dado el ámbito público en el que se suelen mover nuestros proyectos, en cuanto esta licencia empiece a funcionar, no cabe duda de que sera nuestra mejor opción.

Quizás la decisión no sea la más adecuada ya que existen licencias libres para todos los gustos:

• Academic Free License
• Adaptive Public License
• Apache Software License
• Apache License, 2.0
• Apple Public Source License
• Artistic license
• Attribution Assurance Licenses
• New BSD license
• Computer Associates Trusted Open Source License 1.1
• Common Development and Distribution License
• Common Public License 1.0
• CUA Office Public License Version 1.0
• EU DataGrid Software License
• Eclipse Public License
• Educational Community License
• Eiffel Forum License
• Eiffel Forum License V2.0
• Entessa Public License
• Fair License
• Frameworx License
• GNU General Public License (GPL)
• GNU Library or “Lesser” General Public License (LGPL)
• Historical Permission Notice and Disclaimer
• IBM Public License
• Intel Open Source License
• Jabber Open Source License
• Lucent Public License (Plan9)
• Lucent Public License Version 1.02
• MIT license
• MITRE Collaborative Virtual Workspace License (CVW License)
• Motosoto License
• Mozilla Public License 1.0 (MPL)
• Mozilla Public License 1.1 (MPL)
• NASA Open Source Agreement 1.3
• Naumen Public License
• Nethack General Public License
• Nokia Open Source License
• OCLC Research Public License 2.0
• Open Group Test Suite License
• Open Software License
• PHP License
• Python license (CNRI Python License)
• Python Software Foundation License
• Qt Public License (QPL)
• RealNetworks Public Source License V1.0
• Reciprocal Public License
• Ricoh Source Code Public License
• Sleepycat License
• Sun Industry Standards Source License (SISSL)
• Sun Public License
• Sybase Open Watcom Public License 1.0
• University of Illinois/NCSA Open Source License
• Vovida Software License v. 1.0
• W3C License
• wxWindows Library License
• X.Net License
• Zope Public License
• zlib/libpng license

(Fuente http://opensource.org)