aulambra.com

Los beneficios de la W3C son incuestionables y su trabajo en la estandarización de Internet ha sido excepcional. Si bien siempre se le ha achacado la complejidad de su modelo de trabajo. Los grupos cerrados, la falta de visión global de la industria, el tiempo desde que propone un estándar hasta que lo cierra,…

En este sentido la W3C ha empezado a dar pasos que modifiquen este modelo. Hasta ahora para proponer/crear un estándar había que hacerlo mediante un Working Group. Su nueva idea es crear Community Groups y Business Groups.

Community Groups

La idea es abrirse a los desarrolladores de Internet y ofrecerles toda la infraestructura de la W3C para el desarrollo de estándares. La participación será gratuita y sin cargos. No habrá presión de fechas en la propuesta de nuevos estándares.

La idea de los community groups es la de:

• Fomentar la propuesta de nuevas especificaciones
• Promover la discusión sobre los estándares
• Generar y desarrollar casos de test
• Crear una comunidad alrededor de la innovación

Business Groups

Son grupos dedicados a empresas. De esta manera se quiere generar un foro premium de empresas para desarrollar tecnologías específicas orientadas a industrias.

Con los Business Groups se busca el tener más información de empresas en las especificaciones que genere la W3C.

Si la empresa es un W3C Members no tienen coste en su participación. En caso contrario se tiene un coste anual que va desde $300 a $10.000 dependiendo del tamaño de la empresa.

Parece que a lo largo del verano empezará a funcionar este modelo, de momento puedes encontrar más información sobre las nuevas comunidades en http://www.w3.org/2010/12/community/

El grupo de trabajo Device APIs and Policy Working Group de la W3C está definiendo un nuevo borrador, en este caso es el Calendar API. Dicho API intenta definir de forma genérica el acceso a los eventos de un calendario.

Para ello dentro del Calendar API se definen dos interfaces Calendar y CalendarEvent. El interface Calendar nos permite encontrar eventos o items en el calendario y CalendarEvent define qué es un evento en sí, con su descripción, fecha de inicio y fin, si es recursiva,… El interface CalendarEvent está propuesto de la siguiente forma:

interface CalendarEvent {
  readonly attribute DOMString           id;
  attribute DOMString           description;
  attribute DOMString?          location;
  attribute DOMString?          summary;
  attribute DOMString           start;
  attribute DOMString?          end;
  attribute DOMString?          status;
  attribute DOMString?          transparency;
  attribute CalendarRepeatRule? recurrence;
  attribute DOMString?          reminder;
};

Seguiremos atentos a esta especificación.

¿Cuál es la especificación del Device APIs and Policy Working Group que más te llama la atención?

Al crear una aplicación móvil es muy probable que estemos accediendo a las capacidades del dispositivo. Entre estas capacidades encontramos, sin duda alguna, el punto de poder enviar o consultar los SMS del dispositivo. Las diferentes plataformas de dispositivos móviles nos ofrecen sencillos APIs para poder ejecutar esta tarea.

En este sentido, la W3C, en su papel de estandarizar los lenguajes y APIS ha lanzado el primer borrador del Messaging API. El Messaging API pretende estandarizar la funcionalidad de mensajería en el dispositivo: SMS, MMS y email.

Aunque Messaging API está en un estado inicial (solo están definiendo un método sendMessage) merece la pena seguirla los pasos.

El Messaging API esta gestionado por el Device APIs and Policy Working Group

Authoring Tool Accessibility Guidelines (ATAG) 2.0 está en pleno proceso de actualización y así ha notificado que están siendo actualizados los borradores de la especificación.

ATAG 2.0 es la especificación de la W3C que se encarga de definir como tienen que soportar o ayudar a soportar la accesibilidas las herramientas de autor. Es decir, redes sociales, blogs, gestores de contenidos, editores HTML,… De igual manera, ATAG 2.0, especifica como estas herramientas de autor deben de ser accesibles por si mismas.

Dentro de los documentos de trabajo de ATAG 2.0 encontramos:

• Las directrices de ATAG 2.0
• Guía para saber cómo implementar las directrices de ATAG 2.0

Siempre muy buen trabajo el realizado por la W3C en temas de accesibilidad.

Ya se acerca el verano, el calorcito y las ganas de enredar algo más. ¿Te vas a perder nuestras novedades?

Como siempre seguimos animando para que colaboréis en nuestras webs. ¿Te animas? Pues ponte ponte en contacto con nosotros.

Estas semanas en las webs de aulambra.com encontrábamos:

Línea de Código

• Dígitos de un número
• Cambios en un combo con jQuery
• Filtrar elementos nulos de un array con jQuery
• Filtrar elementos de un array con jQuery
• Bloquear el envío de un formulario con jQuery
• Cargar una matriz por teclado en Java
• Listar las claves de una Hashtable
• Número de ocurrencias en un array
• Depurar una conexión SMTP con Java Mail
• Contraseña aleatoria con php

Una Página Web

• @GoogleWebTeam
• RockMeIt y el navegador social
• IE10 User-Agent
• Listado de estándares de la W3C

W3Api

• HTML:onchange
• jQuery:change()

Esta semana en Dudas de Programación han preguntado las siguientes cosas:

• Manejando arrays
• Cambios de imágenes en Javascript
• Conectar JSP con Oracle
• Cerrar una ventana en jQuery
• Cómo generar IDs únicos y autoincrementales en Java
• … además puedes ayudar a resolver las preguntas sin respuesta.

¿Algún foro que no tengamos y que te gustaría crear? Contacta con nosotros.

Recuerda que nos puedes seguir en Twitter:

• @aulambra
• @ayudaenlaweb
• @lineadecodigo
• @unapaginaweb
• @dudasprogamar

O hacerte fan en Facebook de Aulambra, Linea de Código, Una Página Web, Ayuda en la Web o Dudas de Programación.

Cuánta gente que a lo largo de los años ha estado relacionada con el HTML ha buscado el logo del lenguaje… y es que simplemente no existía ninguno estándar. Parece ser que el grupo involucrado en HTML5 ha reparado en eso y ha entendido que el lenguaje con el que estarán hechas todas las páginas del futuro (qué atrevido) tenga su logo.

Pronto veremos correr como un reguero de pólvora el nuevo logo de HTML5 en muchas páginas de Internet… Nosotros ya lo tenemos en nuestra página de ejemplos sobre HTML5.

Pero la cosa no queda aquí, ya que a parte del logo de HTML5, cada una de las partes de la especificación de HTML5 pasa a tener su propio logo.

Echarles un vistazo…

Styling	Semantics	Performance
Offline	Multimedia	Device Access

Ya se pueden encontrar sticks, posters, camisetas,… mucho merchandising del logo HTML5.

Ponte al tanto de todo sobre el logo de HTML5 en http://www.w3.org/html/logo/

El W3C va avanzando en su afán de estandarizar todo lo posible. En esta línea acaba de publicar la recomendación del lenguaje Ink Markup Language (InkML).

El lenguaje InkML servirá para estandarizar el contenido que sea introducido mediante bolígrafos digitales. De esta forma estandarizará la forma en la que se recoge el texto, los gestos, dibujos,…

La especificación para los bolígrafos digitales podrá ser un avance en la estandarización del acceso a la información proporcionada por dispositivos reconocedores de firma. Un tipo de dispositivo que se esta extendiendo mucho últimamente.

Todo el trabajo es coordinado por el W3C MultiModal Interaction Working Group.

El HTML Working Group sigue trabajado, lento pero seguro (no teníamos noticias suyas desde marzo de este año), alrededor del HTML5. Y ha publicado actualizaciones en 8 documentos:

• Nuevo borrador de la especificación HTML5
• Diferencias entre HTML4 y HTML5
• API de referencia HTML
• HTML+RDFa 1.1
• HTML Microdata
• HTML Canvas 2D Context
• Técnicas HTML5 para ofrecer alternativas de texto útiles – documento que nos enseña a como proponer alternativas útiles a las imágenes.
• Polyglot Markup – o como generar documento XHTML compatibles con HTML.

Todos de recomendada lectura.

La W3C está definiendo, vía el Web Application Working Group, un interface estándar para conocer y poder medir el progreso de carga de un elemento. Por ejemplo, si estamos descargando un documento, saber como va,…

Para ello ha generado el borrador Progress Event. En este borrado podemos ver el interface propuesto para la conocer el progreso de carga.

interface ProgressEvent : Event {
  readonly attribute boolean lengthComputable;
  readonly attribute unsigned long long loaded;
  readonly attribute unsigned long long total;

  void initProgressEvent(DOMString typeArg, boolean canBubbleArg, boolean cancelableArg, boolean lengthComputableArg, unsigned long long loadedArg, unsigned long long totalArg);
};

Esto va encaminado en el ámbito de estandarización de las aplicaciones RIA.

Ya hemos vuelto de nuestras vacaciones y volvemos pletóricos de energías. Primera semana de las webs y un montón de cosas publicadas. Además, damos la bienvenida a Una Página Web. Una nueva web de aulambra.com dedicada a los arquitectos del software. Ya la iremos descubriendo poco a poco en esta sección. Espero que os guste.

Y como siempre seguimos animando para que colaboréis en nuestras webs. ¿Te animas? Pues ponte ponte en contacto con nosotros.

Estas semanas en las webs de aulambra.com encontrábamos:

Linea de Código

• Calcular signo del zodiaco con Java
• Restar dos números con Java
• Crear un objeto con métodos en Javascript
• La historia no oficial sobre los Applets de Java
• Conocer el tipo de una variable en VBScript
• La W3C crea el Web Performance Working Group
• Crear un objeto en Javascript

Ayuda en la Web

• Subir fotos a FotoLog
• ¿Qué es last.fm?
• Buscar canciones de un grupo o artista en Spotify
• ¿Qué es Foursquare?
• ¿Qué es FotoLog?

Una Página Web

• El arquitecto web
• Mapa de las redes sociales
• Encuesta sobre accesibilidad

W3API

• Java:JComponent
• Java:Container