Vistas

D 3.3 Documento de especificación de la Plantilla estándar de representación de recursos sensibles al contexto

De MorfeoWiki

PROFIT

Morfeo-EzWeb

Área Temática: 350405 Strategic Action on Open Source Software
FIT-340503-2007-02 EzWeb



Morfeo project EzWeb

Entregable:

D 3.3 Documento de especificación de la Plantilla estándar de representación de recursos sensibles al contexto





Versión: 1.0
Fecha de preparación: 26/11/07
Editores: CodeSyntax
Revisores: TID, Integrasys


Tabla de contenidos

[editar]

Planteamiento

Se trata de determinar la interfaz entre la plataforma EzWeb y los diferentes proveedores de recursos y herramientas.

El objetivo es establecer una interfaz bien definida que permita su utilización por parte de los proveedores de manera sencilla y clara, para facilitar la aceptación y el crecimiento de la plataforma, mediante la incorporación de recursos de proveedores externos como hacen por ejemplo Facebook, Slide o iGoogle, o de recursos de proveedores internos.

Se trata de establecer la plantilla con los estándares de definición y creación de los recursos.

[editar]

Introducción

EzWeb es una plataforma de desarrollo sobre la cual el programador puede construir pequeñas aplicaciones o "gadgets" que un usuario de EzWeb cualquiera puede instanciar en su entorno de ejecución o "dashboard".

El desarrollador debe programar el gadget en lenguaje xhtml y javascript, conforme a una serie de reglas establecidas por el API EzWeb. Además del cuerpo del gadget propiamente dicho, el desarrollador deberá escribir una "plantilla" en formato xhtml, que permitirá incluir el gadget en el seno de la plataforma EzWeb.

En esta plantilla se recogerán todos los detalles de implementación que no tienen que ver con la "capa de negocio" en sí, del gadget. Estos detalles no están fuertemente relacionados con la forma en que gadget lleva a cabo las operaciones y cálculos, sino más bien con los datos que alimentan dichos procesos y la forma en que el gadget va a conseguir estos datos.

[editar]

La información que aparece en la plantilla

Para que un gadget pueda ejecutarse correctamente sobre la plataforma EzWeb es necesario que queden descritos de forma explícita ciertos pormenores sobre el modelo de datos que el gadget maneja. En este sentido, la plantilla recogerá detalles sobre:

  • las preferencias que el usuario del gadget puede modificar y guardar,
  • otras propiedades persistentes que el própio código del gadget puede leer y modificar,
  • los eventos que el gadget puede propaga por toda la plataforma EzWeb
  • y la forma de reaccionar frente a eventos generados por otros gadgets.
[editar]

Preferencias de usuario

En cuanto a las preferencias de usuario, la plantilla expresará de manera declarativa, los datos que el usuario podrá ver y configurar. La plataforma se encargará de hacer estos valores persistentes, así como de proveer al usuario de herramientas para la edición y validación de estos datos. El programador de gadgets no tiene que preocuparse de programar una interfaz para modificar estas preferencias, sino que la plataforma EzWeb genera automáticamente un interfaz apropiado para cada variable, en función del tipo de dato. El código fuente del gadget, podrá acceder a estas variables en todo momento, sin embargo debe tener en cuenta que pueden ser modificadas por el usuario de forma arbitraria.

[editar]

Variables de estado

Otro tipo de variables que deberán explicitarse en la plantilla son las relativas al estado del gadget. Este tipo de datos pueden cambiar a lo largo de la ejecución del gadget sin que el usuario del mismo se vea involucrado. No pueden ser modificadas por el usuario a través de ningún interfaz ni se llevará a cabo ningún chequeo adicional sobre esos datos. Sin embargo, la plataforma EzWeb debe conocer cuáles son estas variables y de qué tipo son, para poder asegurar la persistencia de estos valores. El desarrollador no tiene que preocuparse de ningún aspecto adicional sobre la persistencia de estos datos.

[editar]

Eventos

En relación a los eventos, la plantilla guarda información sobre dos tipos básicos de datos:

  • los slots
  • y los eventos


Las ranuras o "slots" hacen referencia a los eventos a los que puede responder el gadget mediante ciertos manejadores. Estas slots pueden ser accedidas, en modo lectura, desde el código fuente del gadget. Sin embargo, solo pueden ser modificados mediante eventos disparados por algun gadget de la plataforma EzWeb. Este tipo de variables deben estar expecificadas en la plantilla para que la plataforma EzWeb se encargue de actualizarlas cada vez que algún gadget de la plataforma genera el evento adecuado.

Los eventos que el propio gadget produce deben ser explicitados también el la plantilla. Estas variables serán modificadas desde el código fuente del gadget. De hecho es la única forma de modificarlas. Para el desarrollador del gadget, disparar un evento significa modificar una de estas variables. La plataforma EzWeb se encarga de exportar y propagar el evento y hacer saber al resto de los gadgets que el valor ha cambiado.

Una vez que el usuario ha instanciado varios gadgets en su dashboard, puede establecer conexiones entre eventos y slots, denominadas "canales". Estas asignaciones pueden ser realizadas "en caliente" y tendrán un caracter persistente sobre la plataforma EzWeb.

[editar]

Otra información

Por otro lado, en la plantilla aparece otro tipo de información más relacionada con la catalogación y recuperación de gadgets. Esta información consiste en varios campos de datos básicos, por ejemplo: el autor, la versión, fecha de creación, etc.

Además, existe la posibilidad de insertar campos libres, sin un significado a priori para la plataforma y sin un comportamiento predeterminado asociado, para cubrir las necesidades no previstas en cuando a funcionalidad asociadas a la plantilla. Mediante estos campos se posibilita la innovación permitendo darle a ese campo novedosas utilizaciones.

[editar]

Análisis y definición de Plantillas estándar de representación de recursos

Una de las claves del éxito de una plataforma de desarrollo radica en la forma en que se divulga su modo de uso. La plantilla estándar de representación de recursos es la pieza más importante en el puzle que el programador ha de componer para incorporar un gadget u otro recurso a la plataforma ezweb.

En ese sentido, la elección y definición de la plantilla ha sido uno de los trabajos maestros de la implementación de la plataforma. Sin embargo, sin una forma completa y unívoca de expresar lo que una plantilla puede ser o no, la usabilidad del proyecto estaría en grave riesgo. Este es el propósito de esta seción: describir de forma coherente y formal la plantilla estándar de descripción de recursos.

Por un lado, presentamos un estudio de las diferentes formas en que otras plataformas muestran la información e ilustran al programador usuario la forma en que se deben escribir las plantillas insertar recursos o gadgets en cada plataforma.

Tras este estudio, trataremos de describir la forma en que se deben escribir las plantillas para la plataforma de desarrollo ezweb. En este empeños presentaremos, primero de un modo formal y preciso y luego en un registro más divulgativo, las características del lenguaje de plantillas empleado en ezweb.

Por último, presentaremos la estrategia que se va a llevar a cabo para conseguir que el lenguaje de plantillas que hemos modelado sea reutilizado y considerado como un estándar internacional de representación de recursos mediante plantillas.

[editar]

Casos de éxito

Antes de documentar la forma en que la plataforma ezweb hace uso de la plantilla estántar de representación de recursos, hemos hecho un profundo estudio sobre el estado del arte en cuanto a descripción y documentación de modos de uso similares. Para ello hemos recurrido a las plataformas más extendidas entre los usuarios y hemos observado con atención las distintas estrategias de transferencia de información que emplean las más grandes compañías e iniciativas a la hora de poner por escrito las instrucciones de uso de cada plataforma.

Los distintos proveedores de documentación emplean una gran variedad de recuros. Es común la utilización de ejemplos de variada dificultad, desde una aplicación con funcionalidad extremadamente básica (el típico "hola mundo") hasta complejos ejemplos que demuestran una funcionalidad más avanzada. El gradiente y rango de la dificultad de los ejemplos expuestos varia de unos proveedores a otros. Lo más extendido es elevar paulatinamente y de forma suave la dificultad de los ejemplos.

En lo relativo a la información puramente técnica, se considera una práctica común exponer, en forma de referecia, todos los métodos o funciones disponibles para el usuario. Una referencia es un listado exhaustivo de todos lo que un programador pueda llegar a necesitar mientras explota los recursos de una plataforma.

En este sentido, los casos visitados utilizan distintos enfoques. Algunos ofrecen una documentación estática, con ejemplos enlazados desde la referencia o bien insertados en la misma. Otras referencias incorporan un sistema de comentarios, notas o tickets, que aportan un valioso mecanismo de feedback para usuarios y desarrolladores así como para redactores de documentación técnica.

Quizás el enfoque más evolucionado y avanzado es el que proponen algunas tecnologías ofreciendo una documentación en forma de wiki, o modificable en colaboración y en tiempo real. De esta forma, la documentación cobra una vida que dificilmente se alcanzaría de alguna otra manera. Los tiempos de corrección de errores pueden reducirse hasta valores mínimos. Además no hay casos que avalen el miedo al vandalismo y sí que los hay a favor del poder autoregenerador de la documentación escrita de forma colaborativa.

[editar]

Definición formal de la representación de plantillas de recursos para incorporación de servicios, gadgets y contenidos

La plantilla ezweb responde a unas normas sintácticas firmes. Hay que recordar que es un documento que va a ser procesado automáticamente y que la plataforma va a utilizar para conocer las diferentes propiedades que ha de tener en cuenta para mostrar un gadget dado al usuario que lo utiliza. Para poder llevar a cabo esta tarea, la plantilla debe estar escrita en un lenguaje formal.

La forma más extendida de crear un lenguaje formal es utilizando XML. Este metalenguaje nos ofrece un conjunto genérico de normas, que nos indica las pautas generales para poder expresar las características del gadget al que describe. El siguiente paso es acotar las posibilidades que ofrece XML. En ese sentido definiremos un nuevo conjunto de normas sobre XML para que la plataforma ezweb pueda interpretar de forma correcta la plantilla de cualquier gadget que respete dichas normas. Estas normas podrían expresarse mediante varias técnicas, pero es necesario alguna que nos permita establecer una descripción formal. Algunos ejemplos son DTD (http://es.wikipedia.org/wiki/DTD) o XML SCHEMA (http://www.w3.org/XML/Schema).

Con estos lenguajes se pueden definir normas sintácticas que definen la forma en la que estríctamente se puede escribir un XML. En nuestro caso hemos elegido DTD que es un lenguaje un poco más reducido que XML SCHEMA, pero que sin embargo nos va a permitir expresar todos los tipos de restricciones que deseamos.

Citando la wikipedia, las siglas DTD significan en inglés Document Type Definition Definición del tipo de documento. La definición de tipo de documento (DTD) es una descripción de estructura y sintaxis de un documento XML o SGML. Su función básica es la descripción del formato de datos, para usar un formato común y mantener la consistencia entre todos los documentos que utilicen la misma DTD. De esta forma, dichos documentos, pueden ser validados, conocen la estructura de los elementos y la descripción de los datos que trae consigo cada documento, y pueden además compartir la misma descripción y forma de validación dentro de un grupo de trabajo que usa el mismo tipo de información.

La definición formal en formato DTD para la plantilla estándar de definición de recuros es la siguiente: 


<!DOCTYPE Template [

<!ELEMENT Template (Catalog.ResourceDescription, Platform.Preference, Platform.StateProperties, Platform.Wiring, Platform.Context, Platform.Link, Platform.Ren\dering)>
<!ELEMENT Catalog.ResourceDescription (Vendor, Name, Version, Author, Mail, Description, ImageURI, WikiURI)>
<!ELEMENT Vendor (#CDATA)>
<!ELEMENT Name (#CDATA)>
<!ELEMENT Version (#CDATA)>
<!ELEMENT Author (#CDATA)>
<!ELEMENT Mail (#CDATA)>
<!ELEMENT Description (#CDATA)>
<!ELEMENT ImageURI (#CDATA)>
<!ELEMENT WikiURI (#CDATA)>

<!ELEMENT Platform.Preferences (Preference*)>
<!ELEMENT Preference (#EMPTY)>
<!ATTLIST Preference name CDATA #IMPLIED>
<!ATTLIST Preference type CDATA #IMPLIED>
<!ATTLIST Preference description CDATA #IMPLIED>
<!ATTLIST Preference label CDATA #IMPLIED>

<!ELEMENT Platform.StateProperties (Property*)>
<!ELEMENT Property (#EMPTY)>
<!ATTLIST Property name CDATA #IMPLIED>
<!ATTLIST Property type CDATA #IMPLIED>
<!ATTLIST Property label CDATA #IMPLIED>

<!ELEMENT Platform.Wiring (Event*,Slot*)>
<!ELEMENT Event (#EMPTY)>
<!ATTLIST Event name CDATA #IMPLIED>
<!ATTLIST Event type CDATA #IMPLIED>
<!ATTLIST Event label CDATA #IMPLIED>
<!ATTLIST Event friendcode CDATA #IMPLIED>
<!ELEMENT Slot (#EMPTY)>
<!ATTLIST Slot name CDATA #IMPLIED>
<!ATTLIST Slot type CDATA #IMPLIED>
<!ATTLIST Slot label CDATA #IMPLIED>
<!ATTLIST Slot friendcode CDATA #IMPLIED>

<!ELEMENT Platform.Context (Context*,GadgetContext*)>
<!ELEMENT Context (#EMPTY)>
<!ATTLIST Context name CDATA #IMPLIED>
<!ATTLIST Context type CDATA #IMPLIED>
<!ATTLIST Context concept CDATA #IMPLIED>
<!ELEMENT GadgetContext (#EMPTY)>
<!ATTLIST GadgetContext name CDATA #IMPLIED>
<!ATTLIST GadgetContext type CDATA #IMPLIED>
<!ATTLIST GadgetContext concept CDATA #IMPLIED>

<!ELEMENT Platform.Link (XHTML)>
<!ELEMENT XHTML (#EMPTY)>
<!ATTLIST XHTML href CDATA #IMPLIED>

<!ELEMENT Platform.Rendering (#EMPTY)>
<!ATTLIST Platform.Rendering width CDATA #IMPLIED>
<!ATTLIST Platform.Rendering height CDATA #IMPLIED>
[editar]

Ejemplo de platilla para un gadget


<Template schemaLocation="http://morfeo-project.org/2007/Template">

    <!-- Meta tags define gadgets properties -->
    <Catalog.ResourceDescription>
        <Vendor>Morfeo</Vendor>
        <Name>Device_Data_Viewer</Name>
        <Version>1.0</Version>
        <Author>lmayllon</Author>
        <Mail>lmayllon@tid.es</Mail>
        <Description>This gadget shows the information relates to a devide</Description>
        <ImageURI>http://myimages/devices/samples.jpg</ImageURI>
        <WikiURI>http://mywiki/Device_Data_Viewer</WikiURI>
    </Catalog.ResourceDescription>

    <!-- EzWeb Gadgets Tags -->
    <Platform.Preferences>
        <Preference name="bg" type="text" description="background color" label="background color"/>
        <Preference name="textcolor" type="text" description="Text color" label="text color"/>
    </Platform.Preferences>

    <!-- EzWeb Gadget Persistent State -->
    <Platform.StateProperties>
        <Property name="note" type="text" label="note"/>
    </Platform.StateProperties>

    <!-- EzWeb Gadget Data Wiring -->
    <Platform.Wiring>
        <Event name="deviceAddress" type="text" label="Address" friendcode = "deviceAddress" />
        <Slot name="deviceVendor" type="text" label="Vendor" friendcode = "deviceVendor" />
        <Slot name="deviceModel" type="text" label="Model" friendcode = "deviceModel" />
        <Slot name="deviceId" type="text" label="Identifier" friendcode = "deviceIdentifier" />
    </Platform.Wiring>


    <!-- EzWeb Gadget Data Context -->
    <Platform.Context>
        <Context name="user" type="text" concept="user_name"/>
        <GadgetContext name="width" type="text" concept="width"/>
        <GadgetContext name="height" type="text" concept="height"/>  
    </Platform.Context>

    <!-- EzWeb Gadget Code related -->
    <Platform.Link>
        <XHTML href="http://mycode/DeviceDataViewer.html"/>
    </Platform.Link>

    <!-- EzWeb Gadget rendering -->
    <Platform.Rendering width="3" height="11"/>

</Template>

Como se puede ver en el ejemplo que hemos adjuntado, la plantilla estándar consta de varios apartados. Aunque toda la información que necesita la plataforma en relación a este gadget va concentrada en una sola plantilla, no es posible incluir todos los datos de forma desordenada y desectructurada. Para facilitar tanto la lectura como la interpretación de la plantilla hemos decidido agrupar los datos según la familia semántica a la que pertenezcan, de esta forma, no cabe esperar un dato relativo a cómo se indexará el gadget o recurso en el catálogo de la plataforma junto a otro sobre qué eventos disparará el gadget sobre la plataforma.

La clasificación de los datos se realiza mediante los siguientes grupos:

  • Descripción de recuros para el catálogo (Catalog.*)
    • Datos relativos a cómo debe ser indexado el gadget (Catalog.ResourceDescription)
  • Especificación de datos sobre la plataforma ezweb (Platform.*)
    • Preferencias para la plataforma alterables por el usuario (Platform.Preferences)
    • Estado del gadget o elementos persistentes del mismo (Platform.StateProperties)
    • Elementos que participan en la interconexión del gadget con otros gadgets de la plataforma (Platform.Wiring)
    • Los datos relativos al contexto de ejecución del gadget (Platform.Context)
    • Recursos externos que están directa o indirectamente relacionados con el gadget (Platform.Link)
    • Capa de presentación o datos relacionados con la representación del gadget sobre la plataforma (Platform.Rendering)

Cada grupo tiene capacidad para un conjunto de variables que especifican todos los datos necearios reltivos a cada grupo.

[editar]

Ejemplo del código fuente de un gadget


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script language="javascript" src="/ezweb/js/EzWebAPI/EzWebAPI.js"></script>
<style>
#nota{
	display:block;
	border:1px solid black;
	color:black;
        font-size:13pt;
	font-family:"Comic Sans MS";
	width:100%;
	height:100%;
	background: #f0e68c;
	}
</style>

<script language="JavaScript">
var nota = EzWebAPI.createRWGadgetVariable("nota");
var bg = EzWebAPI.createRGadgetVariable("bg", setColorbg);
var textcolor = EzWebAPI.createRGadgetVariable("textcolor", setColorTexto);

function setValue ()  {
   document.getElementById('nota').value= nota.get();
}

function save(formulario){
	nota.set(formulario.nota.value);
}

function delnote(){
	nota.set("");
}

function setColorbg(color){
	var f = document.getElementById("nota");
	
	f.style.background= color;
}
function setColorTexto(color){
	var f = document.getElementById("nota");
	
	f.style.color= color;
}
function load(){
	document.getElementById('nota').value= nota.get();
	document.getElementById('nota').style.height= window.innerHeight - 42 + "px";
        document.getElementById('nota').style.background=bg.get();
        document.getElementById('nota').style.color=textcolor.get();
}
</script>

</head>
	<body onload="javascript:load();">

		<form id="formulario" onsubmit="return false;">	

			<textarea id="nota"></textarea>
			<center>
				<button onclick="javascript:save(this.form)">Guardar</button>
				  
				<input type="reset" value="Borrar" onclick="javascript:delnote()"/>
			</center>
		</form>	
	</body>

</html>

En el ejemplo de código fuente de gadget, se muestra cómo el programador es libre para escribir tanto el xhtml como el javascript que quiera.

[editar]

Metadatos para el catálogo

Como hemos apuntado someramente, la plantilla estándar de descripción de recursos alberga una sección dedicada exclusivamente a la forma en que el gadget o el recurso será indexado en el catálogo de recursos.

En esta sección se incluirán los valores mediante los cuales el catálogo organizará los gadgets. Es de suponer, que de esta información depende el que un usuario recupere o no este gadget, mientras busca en el catálogo de recursos.

Esta sección recibe el nombre de "Catalog.ResourceDescription" y contiene varios apartados que se enumeran e introducen a continuación:

  • "Vendor" Este campo Contiene el nombre que identifica a la persona o institución que libera el gadget. Este nombre clasifica de forma definitiva y casi unívoca el gadget, lo que lo hace inconfundible respecto a gadgets de otros productores, por muy similares que sean los enfoques utilizados en su producción.
  • "Name" Este segundo nombre, en combinación con el del fabricante, sí que identifican de forma exclusiva cada gadget. Esta información debería ser suficientemente significativa como para permitir a un usuario reconocer la funcionalidad del gadget. Si no es así, aún puede consultar el resto de metadatos que aparecen a continueación.
  • "Version" Es posible que nuevas revisiones de un gadget rompan la compatibilidad respecto a versiones anteriores (compativilidad hacia atrás). Si un usuario necesita mantener su gadget desactualizado por algún motivo como este, tendrá que prestar adecuada atención a este gadget. En él se expresará, de una forma coherente la versión del gadget liberado. Cabe esperar que en él se reconozcan la rama de producción (estable, inestable, etc.) y el número de versión en sí mismo.
  • "Author" Este metadato explicita quién ha sido el desarrollador del gadget o recurso. Además de la nota de reconocimiento que cabe esperar en todo producción intelectual, este campo permite abrir una via más de comunicación para hacer llegar el feedback de los usuarios del gadget hasta el equipo de desarrollo.
  • "Mail" Este campo está preparado para albergar la dirección de correo electrónico del autor o de la persona de contacto. Esta información resulta de estimable ayuda si el usuario desea conocer más detalles sobre el producto o si quiere hacer llegar cualquier sugerencia respecto al recurso o gadget que pueda interesar al autor o al equipo de desarrollo. Este campo complementa al metadato "Author" a la hora de presentar la información de contacto del recurso o gadget.
  • "Description" Es un campo de texto libre. En él aparece una descripción, en lenguage natural del gadget o recurso, en la que se habla de la funcionalidad del mismo y se tratan las características que el desarrollador o quien lo publica cree adecuado resaltar. Es conveniente aclarar que de la calidad de estos información, dependende en gran medida la popularidad del gadget o recurso y el número de usuarios que recuperan dicho elemento mientras realizan sus búsquedas y consultas al catálogo.
  • "ImageURI" Este campo contiene una URI, es decir, sigue un formato estándar para identificar un recurso de forma unívoca en Internet. En este caso, el recurso identificado ha de ser una imagen. Esta imagen debe ser un icono representativo del gadget o recurso que se está describiendo. El catálogo utilizará esta imagen en forma de vista previa de modo que el usuario se haga una idea general respecto al aspecto del gadget o recuros.
  • "WikiURI" En esta ocasión, también es necesario la inclusión de una URI en este campo. Sin embargo, el recurso enlazado ha de ser un wiki. El objetivo de este wiki es proveer de un marco de expresión a los usuarios del gadget o recurso donde quepan las evaluaciones, observaciones, opiniones personales que deriben del uso del elemento en cuestión. Gracias a este wiki, los usuarios que recuperen este elemento del catálogo tendrán un valioso conjunto de terceras impresiones respecto al funcionamiento, eficacia o efectividad del gadget o recurso.
[editar]

Información para la plataforma ezweb

Por otro lado, la plataforma ezweb requiere ciertos datos para que la conexión entre el gadget y la plataforma sea fructífera. En esta sección de la plantilla, el programador deberá especificar todos aquellos aspectos que incumban a la plataforma, bien por que de ellos dependa la forma en que la plataforma deba dibujar el gadget o bien porque el comportamiento del propio gadget u otros gadgets venga definido o influenciado por alguno de estos valores.

  • La primera de todas es "Platform.Preferences" y en ella se describen mediante una sintaxis muy concreta las variables de tipo preferencia que va a manejar el recurso o el gadget. Una variable de tipo preferencia es aquella que permite ser modificada por el usuario y que a su vez, la plataforma va a almacenar de forma persistente.
    • Cada preferencia se expecifica mediante el elemento "Preference" y es posible especificar ciertos aspectos de dicha preferencia mediante los atributos del elemento:
      • "name" recoge el nombre de la preferencia, es la forma en que tanto la plataforma, como el programador del gadget se referirá a la preferencia
      • "type" describe la naturaleza de la preferencia. Es decir, que explicita si dicha variable puede contener un valor entero, una cadena de caracteres, u otro tipo de datos más complejo
      • "description" alberga un texto descriptivo sobre la preferencia de la que estamos hablando. Este texto solamente es informativo y su único uso será la construcción automatizada de formularios de edición por parte de la plataforma ezweb.
      • "label" contiene igualmente un texto, pero de naturaleza más corta que en el atributo anterior y servirá, de igual forma, para dibujar formularios de forma automática.
  • "Platform.StateProperties" recoge las variables que, al margen de ser persistentes, solo son modificables de forma programática por el mismo código fuente del gadget o recurso. Esto significa que, a diferencia de las anteriores variables, no son modificables por el usuario del gadget.
    • Cada variable de tipo propiedad de estado se define en esta sección mediante el elemento "StateProperty" y su especificación, al igual que en el anterior caso, se lleva a cabo a través de los atributos del elemento:
      • "name" recoge el nombre de la propiedad, es la forma en que tanto la plataforma, como el programador del gadget se referirá a la propiedad
      • "type" describe la naturaleza de la propiedad. Es decir, que explicita si dicha variable puede contener un valor entero, una cadena de caracteres, u otro tipo de datos más complejo.
  • "Platform.Wiring" En este apartado se registran las variables cuyo impacto va a superar las fronteras del propio gadget. Las variables definidas en esta sección, serán incorporadas al mecanismo de "wiring" de la plataforma ezweb. Esto significa que otros gadgets podrán utilizarlas para recoger o escribir datos de o sobre ellas. En el apartado de wiring es posible insertar elementos de dos tipos:
    • Event. Este elemento permite describir un elemento de tipo 'salida'. La plataforma ezweb entiende que si una variable es de tipo 'salida' otros gadgets podrán recoger el valor que este gadget exporte mediante dicha variable. Existen ciertos datos que es necesario especificar mediante los siguientes atributos:
      • name recoge el nombre de la propiedad, es la forma en que tanto la plataforma, como el programador del gadget se referirá a la propiedad.
      • type describe la naturaleza de la propiedad. Es decir, que explicita si dicha variable puede contener un valor entero, una cadena de caracteres, u otro tipo de datos más complejo
      • label contiene un texto breve que describe, de forma somera, el propósito de la propiedad.
      • friendcode es un identificador que servirá para establecer conexiones programáticas en forma de atajos. Gracias al valor de este campo, es posible establecer relaciones entre gadgets sin depender del interfaz estándar que la plataforma ezweb proporciona para llevarlas a cabo de forma ortodoxa
    • Slot. Mediante este elemento se especifica una variable de tipo entrada. Esto significa que el gadget tendrá la oportunidad de importar datos que otros gadgets hayan escrito previamente en esta variable. Al igual que las variables de salida, existen ciertos atributos que se pueden utilizar para especificar ciertas valores interesantes para la plataforma de wiring:
      • name recoge el nombre de la propiedad, es la forma en que tanto la plataforma, como el programador del gadget se referirá a la propiedad.
      • type describe la naturaleza de la propiedad. Es decir, que explicita si dicha variable puede contener un valor entero, una cadena de caracteres, u otro tipo de datos más complejo
      • label contiene un texto breve que describe, de forma somera, el propósito de la propiedad.
      • friendcode es un identificador que servirá para establecer conexiones programáticas en forma de atajos. Gracias al valor de este campo, es posible establecer relaciones entre gadgets sin depender del interfaz estándar que la plataforma ezweb proporciona para llevarlas a cabo de forma ortodoxa
  • Platform.Link El propósito de este apartado es recopilar todos los componentes del gadget que no estén incluidos en la plantilla propiamente dicha. Este mecanismo proporciona un desacoplamiento que permite, por un lado, desconectar el código fuente del gadget de la configuración y descripción relativa a la plataforma ezweb. Por otro lado, permite reutilizar, tanto la plantilla de descripción de recursos, como el código fuente mismo. Por ejemplo, es posible utilizar una misma plantilla para dos formas de programar la funcionalidad descrita en la plantilla. Del mismo modo, sería posible reutilizar el mismo código fuente del gadget para utilizarlo mediante dos o más plantillas diferentes. Así, se podría utilizar la misma lógica de negocio, aunque la solución que tanto el usuario, como la plataforma observan serían potencialmente diferentes.
    • XHTML es el elemento mediante el cual se indica a la plataforma hacia donde enlazar.
      • href lleva la URI del recurso que se está enlazando desde este elemento.
  • Platform.Rendering Este apartado recoge todas aquellas propiedades que la plataforma ezweb debe tener en cuenta a la hora de renderizar el gadget o recurso. Aquí podrán ser definidas todos aquellos valores que influyan en la forma en que la plataforma debe visualizar el mismo. Por ejemplo, las siguientes variables, definen la forma geométrica que tendrá el gadget.
    • width define la anchura que el gadget debe tomar a la hora de renderizarse.
    • height especifica la altura que tomará en el momento que la plataforma lo dibuje.
[editar]

Implementación de parámetros para capturar la información semántica contextual

En la plantilla debe haber cabida para la información semántica relativa al contexto de ejecución de cualquier gadget o recurso. Para tener un conocimiento más profudo acerca de lo que llamamos contexto, conviene repasar el punto 2.1

La plantilla estándar de definición de recursos ofrece un mecanismo flexible para expresar, mediante unas normas sintácticas concretas, las condiciones contextuales que rodean al gadget. Como se recoge en el apartado de formalización del contexto, la plataforma EzWeb, hace uso extensivo del lenguaje de modelado de datos RDF.

Se han definido varios campos en la plantilla destinados a reflejar los diferentes aspectos contextuales. El modelo recogerá los conceptos genéricos necesarios para la definición del contexto en EzWeb como el perfil del usuario, el usuario, los gadgets de la plataforma, etc. Además recogerá una serie de propiedades que permita relacionar las distintas entidades que configuran el contexto: refines, plays, etc. Este modelo está definido en forma de ontología mediante un lenguaje estándar para la construcción de ontologías web. En cualquier caso, este modelo no debería en un principio recoger axiomas específicos para la definición de los diferentes conceptos.

  • La sección dedicada a este propósito es "Platform.Context". Esta sección es el lugar adecuado para declarar un nuevo tipo de variable de solo lectura que viene a recoger el concepto de contexto. En dicha declación debe aparecer el concepto asociado, lo cual nos permitirá dar semántica a la variable.

La plataforma será la encargada de dar valor a este tipo de variables dependiendo de su concepto asociado. Para ello, la plataforma cuenta con una serie de "adaptadores" que serán los encargados de recuperar el valor.

A su vez, este tipo de variables se divide en dos categorias:

  • "Gadget Context" recoge conceptos relativos únicamente al contexto del propio gadget (como ancho, alto, etc),
  • "Context". Las variables aquí definidas recogen terminos cuyo ámbito se extiende a toda la plataforma (como por ejemplo el nombre del usuario).
[editar]

Guías para la anotación semántica de los recursos.

Para describir semánticamente un recurso por medio de la plantilla estándar, el programador de gadgets o el integrador de estos, deberá prestar especial atención a los campos dedicados a ello en la misma plantilla. Como se describe en el apartado "Modelo conceptual del contexto", la forma de anotar semánticamente un recurso deberá ser congruente con el resto de los componentes semánticos de la plataforma.

Básicamente tenemos tres tipos de entidades relevantes para construir la arquitectura semántica de la plataforma: los recursos del marketplace, el contexto y las anotaciones (folksonomías). Estas tres entidades están interrelacionadas entre sí.

  • Descripciones formales de los recursos del marketplace (gadgets, servicios y contenidos) utilizando modelos conceptuales de dominio, ya sean vocabularios controlados o, en el caso más complejo, ontologías. Estas descripciones organizarán los recursos del marketplace clasificándolos de acuerdo a una serie de criterios definidos formalmente: por ejemplo, saber si un gadget es de tipo agenda (AgendaGadget) o un mapa (MapGadget). En la medida de lo posible, el modelo semántico del marketplace reutilizará ontologías y vocabularios ya conocidos que permitan la integración de distintas fuentes de información.

En la sección anterior se describe cuál es la forma en que se insertan estas descripciones formales.

  • Anotaciones informales (folksonomías) de los recursos creados por la comunidad de EzWeb. Como se explica en el entregable 2.3.1, el modelo formal de folksonomía integra los conceptos de ezweb:Annotation y ezweb:Tag con los usuarios que etiquetan y los recursos que son etiquetados.

Estas anotaciones informales pueden aparecer de forma opcional en la plantilla estándar de descripción de recursos. Para incluir estas anotaciones existe la sección "Description.Info".

[editar]

Guía de uso de plantillas de recursos estándar

En este apartado se explica la forma en que ha de hacer uso de la plantilla de recuros estándar. Esta pequeña guia trata de ilustrar al programador de gadgets, los pasos que tiene que seguir para añadirlos a la plataforma explicitando todos los elementos que esta necesita saber sobre el gadget.

En el momento que hayamos definido la funcionalidad de nuestro gadget y programado la aplicación mediante xhtml y javascript, llega el momento de insertarlo en la plataforma. Esta conexión la vamos a realizar mediante la plantilla estándar de descripción de recursos.

1. El primer paso es situar el código fuente de nuestro gadget en una URI accesible a través de Internet.

2. Después conviene situar una imagen en otra URI, para poder referenciarla desde el catálogo de gadgets.

3. También es recomendable habilitar una página wiki en otra URL. Esta característica será utilizada también por el catálogo.

4. A continuación, hay que escribir las diferentes partes de la plantilla. En primer lugar hay que especificar los metadatos para el catálogo: (Vendor, Name, Version, Author, Mail, Description) y rellenar las URLs de la imagen y del wiki en los campos ImageURI y WikiURI. 

  <Catalog.ResourceDescription>
    <Vendor></Vendor>
    <Name></Name>
    <Version></Version>
    <Author></Author>
    <Mail></Mail>
    <Description></Description>
    <ImageURI></ImageURI>
    <WikiURI></WikiURI>
  </Catalog.ResourceDescription>

5. En siguiente lugar, corresponde recolectar y recontar las variables que hayamos utilizado en el gadget. El siguiente paso es indicar en cada sección aquellas que hayamos utilizado de cada tipo: (Preferencias, Propiedades o eventos/ranuras) 

  <Platform.Preferences>
  </Platform.Preferences>

  <Platform.StateProperties>
  </Platform.StateProperties>

  <Platform.Wiring>
  </Platform.Wiring>

6. A continuación, es necesario indicar la URI donde está situado el código fuente. 

  <Platform.Link>
    <XHTML href=""/>
  </Platform.Link>

7. Por último, es posible especificar ciertos datos sobre la forma en que el gadget aparecerá en pantalla. 

  <Platform.Rendering width="" height=""/>


[editar]

Selección y transferencia de los nuevos procedimientos a una organización de estandardización internacional de prestigio relevante

Como describimos en los apartados anteriores, la plantilla que describe un recurso está escrita en un lenguaje derivado del XML. Además, este lenguaje está definido mediante su descripción en DTD. Conviene señalar que tanto el metalenguage XMl como la tecnología DTD forman parte de estándares conocidos y reconocidos que además de ser la adopción de-facto por la comunidad de desarrolladores de Internet, forman parte de documentos sobre estandarizaciones de la web.

Esto significa que para el diseño y escritura de plantillas de descripción de recursos ezweb, no es necesario utilizar ninguna tecnología que se aleje de los canones y estándares de programación web. Tenemos la certeza de que esto magnificará sobremanera la difusión y el impacto del proyecto ezweb y la plataforma de desarrollo.

Sin embargo, no nos gustaría detenernos aquí sino que nos gustaría convertir nuestra forma de describir recursos mediante una plantilla en un estandar internacional. Detrás de la plantilla estandar de representación de recursos hay muchas horas de estudio, planificación y diseño con el único propósito de conseguir superar el estado del arte en cuanto a representación formal de recursos y gadgets sensibles al contexto.

Los procedimientos de desarrollo de la plantilla de representación del contexto, han sido diseñados en forma de proceso completo de formalización del contexto que pueda tener cualquier tipo de recurso que pueda ser susceptible de ser incluido, tanto en nuestra plataforma ezweb, o en otras plataformas de similar propósito y enfoque operacional.

Pero para que el caracater eminentemente práctico del estándar diseñado por el equipo ezweb, llegue en verdad al máximo estado de practicidad, es necesario un duro esfuerzo de documentación, divulgación y promoción dentro de diferentes grupos de trabajo y equipos de estandarización que den soporte y apoyo a la propuesta de representación en forma de nuestra plantilla estándar.

En este sentido, hay varios foros en los que nuestra presencia es rigurosamente obligada. La lista de estos foros está formada por una serie de entidades de caracter internacional cuya principal labor es la de consensuar una serie de propuestas tecnólicas con el objetivo de crear un ámbito común intercontinental de innovación y trabajo, en torno a tecnologías emergentes y consolidadas de Intenet.

La primera del listado propuesto es el Instituto de Ingenieros Eléctricos y Electrónicos:

Como cita en la versión española de la wikipedia, IEEE corresponde a las siglas de The Institute of Electrical and Electronics Engineers, el Instituto de Ingenieros Eléctricos y Electrónicos, y se trata de una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Es la mayor asociación internacional sin fines de lucro formada por profesionales de las nuevas tecnologías, como ingenieros eléctricos, ingenieros en electrónica, científicos de la computación e ingenieros en telecomunicación.

Su creación se remonta al año 1884, contando entre sus fundadores a personalidades de la talla de Thomas Alva Edison, Alexander Graham Bell y Franklin Leonard Pope. En 1963 adoptó el nombre de IEEE al fusionarse asociaciones como el AIEE (American Institute of Electrical Engineers) y el IRE (Institute of Radio Engineers).

A través de sus miembros, más de 360.000 voluntarios en 175 países, el IEEE es una autoridad líder y de máximo prestigio en las áreas técnicas derivadas de la eléctrica original: desde ingeniería computacional, tecnologías biomédica y aeroespacial, hasta las áreas de energía eléctrica, control, telecomunicaciones y electrónica de consumo, entre otras.

Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales.

Mediante sus actividades de publicación técnica, conferencias y estándares basados en consenso, el IEEE produce más del 30% de la literatura publicada en el mundo sobre ingeniería eléctrica, en computación, telecomunicaciones y tecnología de control, organiza más de 350 grandes conferencias al año en todo el mundo, y posee cerca de 900 estándares activos, con otros 700 más bajo desarrollo.

Otra de las instituciones candidatas como foro donde publicar nuestra plantilla de representación formal de recursos es la Organización Internacional para la Estandarización:

En palabras de la wikipedia, la Organización Internacional para la Estandarización o International Organization for Standardization (ISO), que nace después de la segunda guerra mundial (fue creada en 1946), es el organismo encargado de promover el desarrollo de normas internacionales de fabricación, comercio y comunicación para todas las ramas industriales a excepción de la eléctrica y la electrónica. Su función principal es la de buscar la estandarización de normas de productos y seguridad para las empresas u organizaciones a nivel internacional. La ISO es una red de los institutos de normas nacionales de 157 países, sobre la base de un miembro por el país, con una Secretaría Central en Ginebra, Suiza, que coordina el sistema. La Organización Internacional de Normalización (ISO), con base en Ginebra, Suiza, está compuesta por delegaciones gubernamentales y no gubernamentales subdivididos en una serie de subcomités encargados de desarrollar las guías que contribuirán al mejoramiento ambiental. Las normas desarrolladas por ISO son voluntarias, comprendiendo que ISO es un organismo no gubernamental y no depende de ningún otro organismo internacional, por lo tanto, no tiene autoridad para imponer sus normas a ningún país.

Es una organización internacional no gubernamental, compuesta por representantes de los organismos de normalización (ON's) nacionales, que produce normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO y su finalidad es la coordinación de las normas nacionales, en consonancia con el Acta Final de la Organización Mundial del Comercio, con el propósito de facilitar el comercio, facilitar el intercambio de información y contribuir con unos estándares comunes para el desarrollo y transferencia de tecnologías.

El Consorcio World Wide Web, abreviado W3C, es otro de los foros a considerar de forma obligada:

El World Wide Web Consortium, según la wikipedia, es un consorcio internacional que produce estándares para la World Wide Web. Está dirigida por Tim Berners-Lee, el creador original de URL (Uniform Resource Locator, Localizador Uniforme de Recursos), HTTP (HyperText Transfer Protocol, Protocolo de Transferencia de HiperTexto) y HTML (Lenguaje de Marcado de HiperTexto) que son las principales tecnologías sobre las que se basa la Web.

Un estándar pasa por los siguientes estados :

  • Working Draft (Borrador de trabajo)
  • Last Call (Última convocatoria)
  • Proposed Recommendation (Propuesta de recomendación) y
  • Candidate Recommendation (Recomendación candidata)

Finaliza con la aprobación de la "Recomendación", lo que equivale a una homologación de la propuesta, es decir, un nuevo estándar público y abierto para la Web. La mayoría de estas recomendaciones son secundadas por los fabricantes de herramientas (navegadores, editores, buscadores) y tecnologías (servicios Web, directorios, registros). Ésta competencia en exclusiva del W3C para crear estándares abiertos es crucial, pues de ella depende que ningún fabricante alcance nunca el monopolio de explotación de la Web.

La inclusión de una propuesta como un estándar internacional requiere una labor ardua pero que sin duda merece la pena como colofón a un trabajo de investigación de la envergadura de morfeo-ezweb. Los procedimientos de estandarización están fuertemente definidos y se componen de una serie de estríctos pasos a través de los cuales las propuestas deben cubrir su ciclo de vida, pasando de las unas manos a otras, siempre bajo la meticulosa observación y el severo escudriñamiento de un equipo de expertos de reconocido prestigio internacional.

Al margen de este esfuerzo, cuyos resultados solo pueden esperarse a medio o largo plazo, es necesario abrir otro frente de divulgación, esta vez en foros no oficiales o institucionales. Esta segunda partida de esfuerzo debe tener el objetivo claro de diseminar el estándar entre las comunidades de software y tecnología centradas en aplicaciones web y servicios orientados al servicio.

Necesitamos que apoyar la candidatura de la plantilla de representación estándar mediante la consagración de nuestra estrategia de definición, en un estándar de-facto entre los desarrolladores de aplicaciones web orientadas a la construcción de gadgets, recursos y otros servicios sobre plataformas sensibles al contexto.

[editar]

Conclusión y líneas para la incorporación de mejoras por usuarios

El modelo que propone ezweb para la escritura de plantillas para la descripción y especificación de recursos se considera completo y consistente. Sin embargo, deberíamos estar muy desorientados si creyesemos que con la propuesta cumplimos y cumpliremos todos y cada uno de las necesidades de los usuarios presentes y futuros.

Ya hemos descrito en el apartado anterior la medida en que la definición de la plantilla es flexible a nuevos campos y aportaciones espontáneas del usuario. Sin embargo, no es imposible que en un futuro la actual sintaxis empleado en la plantilla se antoje obsoleta, por lo que no es descartable que aparezcan nuevas versiones del lenguaje de representación de recursos para la plantilla.

Esta forma de proceder es sensible, las versiones me refiero, por lo que se debe actuar con sumo cuidado de no romper nunca la compatibilidad hacia atrás y mantener una política de información actualizada y precisa sobre las partes del lenguaje rechazadas por obsolescencia.

El flujo de comunicación entre el usuario y los desarrolladores de la plataforma ezweb debe ser fluido y fructuoso. Al igual que cualquier otra comunidad de software libre, la plataforma morfeo-ezweb cuenta con una frondoso despliegue de medios de comunicación en grupo, recogida de feedback y sistemas de soporte a usuarios finales, como se comenta en la sección D.6.1.1 Informe sobre la estrategia de explotación mediante la cual esperamos, todas las propuestas o peticiones que aparezcan en los usuarios tengan un foro de expresión, canalización y adecuado tratamiento.

No hay que olvidar, además, que la comunidad que está desarrollando ezweb es una comunidad abierta desarrolando software libre. En este sentido, la delgada frontera entre los desarrolladores y los propios usuarios es debil y fragil y amenudo elementos de un lado de ella pasen al otro lado. El software libre tiene como una de sus bondades la de permitir ser modificado y redistribuido al antojo o demanda de alguno de sus usuarios, por lo que vemos en la plataforma ezweb la flexibilidad suficiente para afrontar las posibles necesidades futuras y recorrer el margen hasta la adaptación máxima de la aplicación a las necesidades de su comunidad de usuarios.

Obtenido de "http://forge.morfeo-project.org/wiki/index.php/D_3.3_Documento_de_especificaci%C3%B3n_de_la_Plantilla_est%C3%A1ndar_de_representaci%C3%B3n_de_recursos_sensibles_al_contexto"