A document-based approach for WebLab configuration

A document-based approach for WebLab configuration Cássio Prazeres

Department of Computer Science University of São Paulo

[email protected]

Cesar Teixeira

Department of Computer Science Federal University of São Carlos

[email protected]

ABSTRACT

Given that broadband networks make quality user-interaction possible, there is a tendency for web-based laboratories (WebLabs) to allow their experiments to be accessed by remote users. Although problems such as laboratory description and experiment configuration and scheduling are common to most laboratories, WebLabs usually adopt an ad hoc solution with respect to these problems. There is an opportunity for specifying a standard way to describe a WebLab as well as for defining general and specific experiment configuration and presets. Our contributions include XML-Schemas for WebLab description and experiment configuration, as well as a document-based I-TOOLARR system designed to integrate remote experiments into a web-based environment. The I-TOOLARR system makes use of XSLT transformations to generate form-based interfaces that allow users to interactively configure WebLabs in general and associated specific experiments.

Categories and Subject Descriptors

H.5.4 [Hypertext/Hypermedia]:

General Terms

Design, Specification, Experimentation.

Keywords

XML Schemas, XSLT Transformations, WebLabs.

1. INTRODUCTION Broadband networks allow quality user-interaction and, as a result, many laboratories have been extended so that their experiments can be accessed by remote web users. These laboratories are usually called WebLabs when the experiments and associated resources are accessed and controlled via the web.

WebLabs exploit the fact that information flowing at rates gigabits per second and latency lower than the typical human reaction time (around hundreds of milliseconds), make it relevant for users to access laboratories remotely. Examples of successful WebLabs are found in several domains such as robotics [1], telemedicine [19] and engineering [15], giving remote access to resources that are rare or expensive, for instance. In general there are several

situations in which, because it is impossible to execute the experiment locally, it is better to do it remotely than doing nothing.

In the educational domain, in particular, remote laboratories1 have been proposed as another paradigm of experimentation complementing in loco experiences so as to improve education (e.g [14][18][15][11][12][20][10][24][25]).

Some authors (e.g. [14][18]) argument that remote experimentation should not be seen as a replica of in loco

experiments. In fact, an approach does not substitutes the other. They complement each other aiming improve the experience.

Remote experimentation aggregates new objectives to those established for in local experiments. In fact, it is generally accepted that the observation and the remote control of events that happen while an experiment takes place promote:

• improvement of the user's capability to control an interesting phenomenon through networking and computing systems;

• familiarity with resources usually offered by these systems, as real time data processing, which gives feedback for, possibly, relevant decisions during the experiment;

• minimizes the effects of unwanted variables the user could inadvertently introduce with in loco experiments;

• turn explicit the relation among the variables pertinent to the observed phenomenon, since variables not planned for the experiment may not be deliberately manipulated by the users as an alternative way to get the expected results.

In order to be made available on the web, WebLabs must produce information associated with laboratory description as well as experiment configuration and scheduling. Important efforts related to remote experimentation dedicate energy to solve the technical problems involved in offering the remote access to the experiments [18][21][23][13][24][11][12][20][10].

Given that WebLabs usually produce an ad hoc solution for controlling such information, there is an opportunity for specifying a standard way to describe a WebLab as well as for defining experiment configuration and presets.

It is also important to observe that, so far, there is no standard notation for information interchange with respect to WebLabs.

1 From now on, we use also use lab as a synonym of laboratory.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. DocEng’06, October 10–13, 2006, Amsterdam, The Netherlands.

Copyright 2006 ACM 1-58113-000-0/00/0004…$5.00.

Even though each laboratory may be unique with respect to its own configuration, the information dealt with or produced within a lab may be of interest to many individuals outside the organization itself, which calls for a standard representation to leverage interchange.

In such scenario, the contributions we present in this paper include XML-Schemas for WebLab description and experiment configuration and the document-based I-TOOLARR system designed to integrate remote experiments into a web-based environment. The I-TOOLARR system makes use of XSLT transformations to generate form-based interfaces that allow users to interactively configure WebLabs in general and associated specific experiments in particular. The document-based approach used in the implementation of the I-TOOLARR system is domain-independent. Moreover, our document specifications allow laboratory specification interchange. In this paper, we illustrate the use of the I-TOOLARR system considering that WebLabs are to be made available via a web-based plataform for the educational domain.

This paper is organized as follows. Section 2 presents the terminology we use with respect to WebLabs, Resources, TOOLARs and the I-TOOLARR approach, and give an overview of the approach. Sections 3 presents the I-TOOLARR approach, detailing the document-based phases associated with the definition and configuration of WebLabs, TOOLARs and associated experiments. This presentation details the documents used and the actors involved in the specification. A Section 3 presents some related works. Section 4 summarizes our contributions and highlights future works.

2. I-TOOLARR OVERVIEW

We use the following concepts throughout the text:

• WebLabs: Laboratories (institutions) that allow resources to be remotely accessed by means of experiments controlled via a computer network.

• Resources: Resources are collections of one or more resources (recursively) where a resource is anything made available in the context of an experiment: equipment, software, chemicals, live animals, etc. We also refer as a resource to a human being when he or she is a person, in the laboratory, who supports the execution of an experiment (e.g.,a technician) or he or she is an active agent with respect to the experiment (e.g, a tutor who interacts with remote students)

• TOOLARR: (Tool for Accessing Resources Remotely)

A TOOLARR is a software and hardware platform that gives access to several configurable experiments accessible via a network connection. A TOOLARR designer defines how a given TOOLARR is to be composed, including options relative to the list of resources that are made available to experiments, the specification of how those resources can be used, which automation circuits and associated software gives access to resources, which software supports the communication among remote peers, which user interface software is to be used, etc. The configuration

of one particular experiment must take into account the possibilities offered by a given TOOLARR (that is, a single TOOLARR may be used to define several similar experiments). Moreover, the definition of one particular experiment (that exploits a particular TOOLARR) may leave room to further configuration by the individuals who will execute the experiment.

• I-TOOLARR approach: A single TOOLARR gives access to several resources and the configuration of a particular experiment involves several actors in predefined roles: WebLab Administrator, TOOLARR Designer and Registrar2, Experiment Proponent,

Experiment Executor. We have designed I-TOOLARR

as a document-based approach that includes XML Schemas and XSLT transformations generating web-based interfaces used by the several actors.

The process of making an experiment available via the Web must take into account that all actors involved need to, according to their roles, have access to information relative to the WebLab use. This means, for instance, that:

• a WebLab Administrator must register, in the Web-based infra-structure that gives access to the WebLab, general information relative to the laboratory, an may have access to information relative to all TOOLARs associated with the laboratory;

• a TOOLARR Registrar records, in the Web-based infra-structure that gives access to the WebLab, the information the corresponding TOOLAR, as defined by the TOOLARR Designer;

• a Experiment Proponents selects, in the Web-based infra-structure that gives access to the WebLab, information relative to a given experiment configuration as well as potential Experiment Executors; and

• a Experiment Executors accesses, in the Web-based infra-structure that gives access to the WebLab, options relative to the time slots available for the experiment as well as to any options configured by Experiment Proponent (the Experiment Executor may be demanded to configure a particular instrument, for instance).

Considering that there are many tasks that are associated with each of the actors according to their roles, we have designed an approach that, abstracting many aspects that are common to a variety of laboratories, supports the automation of tasks and the reuse of resulting specifications.

In this paper we present the overall approach and an associated implementation. It is important to observe that the approach leverages the availability of XML schemas and XSLT transformations. The schemas and transformations we present are illustrative of the possible specifications demanded by laboratories, administrators, experiment proponents and

2 A TOOLARR Designer defines the resources available by TOOLAR; the TOOLARR Registrar is responsible for registering the TOOLARR within the Web-based infrastructure giving access to the TOOLARR resources.

executors. In other words, the definition of a complete formal recommendation with respect to WebLabs requires discussion by an appropriate forum.

To illustrate our approach, we have implemented the I-TOOLARR system that includes XSL Schemas and XSLT transformations that generates the documents to be used by the actors identified by the I-TOOLARR approach. The system has been implemented in the context of a Web-based e-learning infrastructure, which illustrates the opportunity of having a WebLab made available along with other typical Web tools such as Chat, Instant Messenger, Whiteboard and Wiki-based tools.

The complete life-cycle of a given WebLab involves decisions and associated tasks carried out before, during and after an experiment takes place. In this paper, we detail the document-based processes that allow supported actors (WebLab Administrator, TOOLARR Designer and Registrar, Experiment Proponent, Experiment Executor) to take the necessary decisions demanded before the experiment takes place as well as the accessing the corresponding results after the experiment.

The actions are grouped in four subsystems: (1) WebLab registration, by WebLab Administrators, (2) Specification of properties, configuration parameters and associated presets, by TOOLARR Registrars, (3) Selection of properties, configuration parameters and associated presets, by the Experiment Proponent, (4) Selection of any remaining properties, configuration parameters and associated presets as well as selection of time slots to carry out the experiment by the Experiment Executor.

3. I-TOOLARR IN DETAIL Considering the variety of WebLabs and experiments that can be defined, our approach has been designed to facilitate extension and customization according to new requirements. This has been achieved by intensive use XML Schemas for structuring the information defined not only a priori, considering the WebLabs application domain, but also on-the-fly, to accommodate the unique characteristics of each lab.

The support to the on-the-fly document-based specification is achieved with the intensive use of XSLT transformations that allow the generation of required presentation documents. The on-the-fly processing of the documents is implement within document-processing flows involving XML Schema specifications, XSLT transformations and form-based presentation documents (see Figure 1 for an example).

It is important to observe that, although an interactive approach has been designed to facilitate the use of the system by final users such typical lab administrators and designers, both our approach and our current implementation allows that specification documents be entered directly and, once validated, used throughout the system. This means that it is possible to reuse specifications created for other WebLabs, TOOLARRS or associated Experiments. This possibility is made explicitly in our document flows by allowing an input document to be given as an alternative for the manual filling of the forms (indicated by the MUX multiplex selector in Figure 1).

All documents generated must be sent to the corresponding WebLabs: it may the demanded that particular activities be carried

out by WebLab staff so that the scheduled experiments be executed as planned.

Considering that the document flow can be executed as a typical web-based application, the documents can be also stored for later review or further processing.

Our schemas have been designed to include common information in WebLab configurations such laboratory name, address, director, as well as the definition, scheduling and configuration of remote experiments. Our investigation has included gathering, with some candidate laboratories, a set of metadata which is common to all laboratories so as to make their experiments available on the web. This information was used to define an XML Schema corresponding to a standard way to define lab common metadata information. This schema is processed so as to offer a WebLab manager an automatically generated web form where the common information can be set. Alternatively, an instance of the schema can be used so that the user, instead of filling the forms, offers the corresponding document.

In this remaining of section, we describe the four document-based subsystems corresponding to our current implementation.

3.1 WebLab Registration Our approach assumes that the interactions are carried out by authenticated users in a Web-based environment. The first document flow (see Figure 1) is to be carried out by the (authenticated) actor WebLab Administrator.

The flow starts with the processing of an XML Schema corresponding to information common to most labs by a transformation document, generating a form presented to the WebLab administrator, who fills with information from his lab. Once the form is filled, the corresponding lab specification is validated (to guarantee conformance with datatypes and structure). The administrator uses the same form, iteratively, until all problems are fixed.

More specifically, in Figure 1:

• the XML Schema is indicated by WLC: Web Lab Concept

• the transformation document is indicated by WLC2FORM:

WLC to Form;

• the form presented to the WebLab Administrator is indicated by WLDF: WebLab Description Form;

• the filling of the form by the actor is indicated by MEP:

Manual Editing Process;

• the instance document produced as a result of edition is indicated by WLD: WebLab Description;

• the validation of the information provided by the actor is indicated by VC: validation check;

• the provision of an alternative instance document, possibly from reuse, is indicated by IWLD: Imported WLD;

• the selection between the IWLD document or the information provided manually (via the manual filling of the forms MEP) is indicated with the MUX: multiplex selector.

Figure 1. Document-based flow for WebLab registration.

WLC schema: WebLab Concept (definition). WLC2FORM: transformation specification from WLC to WLDF form. WLDF: WebLab

Description Form. MUX (multiplex): multiple-entry selector. WLD: XML WebLab Description. MEP: Manual Editing Process executed

by authenticated user. IWLD: Imported WLD. VC: Validation Check.

The XML Schema presented in Figure 2 illustrates the type of information demanded to be registered for each laboratory (WLC:

Web Lab Concept in Figure 1). The processing of this document with an appropriate transformation (WLC2FORM in Figure 1) generates the form presented in Figure 3 (WDLF in Figure 1), which is filled in by the lab Administrator (MEP in Figure 1).

<?xml version="1.0" encoding="ISO-8859-1" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:simpleType name="nameType">

<xsd:restriction base="xsd:string">

<xsd:maxLength value="20" />

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="descriptionType">

<xsd:restriction base="xsd:string">

<xsd:maxLength value="400" />

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="webladType">

<xsd:sequence>

<xsd:element name="name" type="nameType"

minOccurs="1" maxOccurs="1"/>

<xsd:element name="url" type="urlType"

minOccurs="1" maxOccurs="1"/>

<xsd:element name="description"

type="descriptionType" minOccurs="1" maxOccurs="1"/>

</xsd:sequence>

<xsd:attribute name="WebLabId" type="xsd:ID" use="required" />

</xsd:complexType>

<xsd:element name="WebLab" type="webladType" />

</xsd:schema>

Figure 2. A segment of the WLC XML-Schema

Figure 3. Sample WebLab Description Form (WLDF)

3.2 TOOLARR Properties and Parameters

Definition Several experiments may be associated with a given WebLab: each experiment is made available by means of a TOOLARR

(Tool for Accessing Resources Remotely). Once the designer of a TOOLARR has defined all the details relative to the resources that will be made available for the corresponding experiments, this information must be registered (by the WebLab Registrar) and validated, so that the corresponding specification can be used to generate documents to be presented to Experiment Proponents and Experiment Executors.

From our interviews with users, we have concluded that the specification of experiments in a TOOLARR can be divided in two parts: general information which is common to most experiments (e.g. name and author), and information that is specific for each experiment. The specific information includes the list of resources associated with the experiment, the parameters associated with each resources, along with the possible values associated with each parameter, and with default (preset) values for each parameter. We have defined a document-based flow for each part, as illustrated in Figure 4.

The actors in Figure 4 are authenticated WebLabs Registrars, who gather the design from the WebLab designers and build specifications both for the general experiment flow and for the specific experiment flow.

The general information is dealt with in the flow presented in top part of Figure 4. The TGCF (TOOLARR General Configuration

Form) is used by the WebLab Registrar to define the general properties of an experiment. This form is generated automatically by processing the schema TGC (TOOLARR General Concept) with the TGC2FROM transformation specification. Upon completion of the form, two documents are automatically generated. One is the document TD (TOOLARR Description)

which contains information relative to the experiment (name, images, etc). The other is the TGCP (TOOLARR General Concept

Propagated), a schema with information to be propagated to other flows to be used by the Experiment Proponent and the Experiment Executor. TGCP includes information related to the timetable allowing the scheduling of the experiment, for instance.

The specific information is dealt with in the flow presented in bottom part of Figure 4. The TSCF (TOOLARR Specific

Configuration Form) is generated automatically upon the processing of the TSCD (TOOLARR Specific Concept Definition)

schema with the TSCD2FORM transformation specification. Once the Registrar successfully completes the form, two documents are generated. One is the TSC (TOOLARR Specific Concept) which, combined with the TGCP generated in the flow specifying the general properties (Figure 4 (top)), specify the grammar of the document that will be to be used by the Experiment Proponent to specify a particular experiment (see Section 3.3) and is also used in the definition of the document to be presented to the Experiment Executor to specify information regarding scheduling and any other specific information that has been designed to be presented to the Experiment Executor (see Section 3.4).

Figure 4. Document flow for TOOLARR Properties (top) and Parameters Definitions (bottom)

(top) TGC schema: TOOLARR General Configuration. TGCF: TOOLARR General Configuration Form. TGC2FORM:

transformation specification from TGC to TGCF form. TGCP schema: TOOLARR General Concept Propagated. ITD: Imported

TOOLARR Descriptor. ITGCP: Imported TGCP. TD instance: TOOLARR descriptor. MEP: Manual Edition Process. MUX

(multiplex): multiple-entry selector. VC: Validation Check.

(bottom) TSCD schema: TOOLARR Specif Concept Definiton. TSCF: TOOLARR Specific Configuration Form. TSCD2FORM:

transformation specification from TSCD to TSCF form. TSC schema: TOOLARR Specific Concept. ITSC: Imported TSC. MEP:

Manual Edition Process. MUX (multiplex): multiple-entry selector. VC: Validation Check.

Figure 5 illustrates an instance of TSCF (TOOLARR Specific

Configuration Form) form in which the WebLab Registrar specifies the attributes and possible values relative to the launching of a projectile. In the figure, the attributes InitialHeight and AngleInclination have already been defined, along with their possible values, and the user is defining the attribute InitialSpeed. The main idea with this approach is to hide from the WebLab staff the complexity in creating a XML Schema.

Figure 5. Filling in a TOOLARR Specific Configuration Form

for a projectile launching TOOLARR

The flows presented in Figure 4 also specify alternative options for document input, which facilitates reuse, for instance. The documents TD, TGCP and TSC may be edited starting with existing versions called ITD (Imported TOOLARR Description), ITGCP (Imported TOOLARR General Concept) and ITSC

(Imported TOOLARR Specific Concept), respectively

3.3 Establishment of Experiment Parameters

Values An Experiment Proponent has to specify, from the set of possible experiments made available via a TOOLARR, which parameters configure the experiment to be carried out by the Executors. This information is specified by the proponent when filling, in the flow indicated in Figure 6, the ECPF (Experiment Configuration

Proponent Form) form. In this case, the schemas generated as a result of the flows that specify the TOOLARR properties ( TGCP

in Figure 4( top)) and TOOLARR parameters (TSC in Figure 4 (bottom)), are used to generate the ECPF (Experiment

Configuration Proponent Form) and in the verification of the document generated as a result of the data provided by the Experiment Proponent, the schema EECC (Executor Experiment

Configuration Concept) and the document PEC (Proponent

Experiment Configuration).

The PEC document registers the configuration registered by the Experiment Proponent. The EECC is a schema used to the generation of the form to be presented to the Experiment Executor, as detailed the the next section.

Figure 7 presents a portion of the XML Schema corresponding to the Projectile Launching Experiment. Figure 8 illustrates the presentation document generated via XSLT transformation.

Figure 6. Document flow for the establishment of experiment parameters values

TGCP schema: TOOLARR General Concept Propagated. TSC schema: TOOLARR Specific Concept. ECPF: Experiment

Configuration Proponent Form. TGC+TSC2FORM: transformation specification from TGC to TGCF form. IEECC schema:

Imported Executor Experiment Configuration Concept. IPEC: Imported Proponent Experiment Configuration. EECC: Executor

Experiment Configuration Concept. PEC instance: Proponent Experiment Configuration. MEP: Manual Edition Process. MUX

(multiplex): multiple-entry selector. VC: Validation Check.

<xsd:complexType name="InitialHeightType">

<xsd:sequence>

<xsd:element name="InitialHeightValue"

minOccurs="1" maxOccurs="1">

<xsd:simpleType>

<xsd:restriction base="xsd:positiveInteger">

<xsd:minInclusive value="1" />

<xsd:maxInclusive value="100" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="AngleInclinationType">

<xsd:sequence>

<xsd:element name="AngleInclinationValue"

minOccurs="1" maxOccurs="1">

<xsd:simpleType>

<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="-90" />

<xsd:maxInclusive value="90" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="attributesType">

<xsd:sequence>

<xsd:element name="InitialHeight" type="InitialHeightType"

minOccurs="1" maxOccurs="1" />

<xsd:element name="AngleInclination" type="AngleInclinationType"

inOccurs="1" maxOccurs="1" />

</xsd:sequence>

</xsd:complexType>

Figure 7. A segment of a TOOLARR Specific Concept

Figure 8. Experiment Configuration Proponent Form: A GUI

automatically generated for an experiment configuration

3.4 Reservation and Remaining Experiment

Parameters Values An Experiment Executor may have the opportunity to configure some parameters relative to the experiment, according with the options established by the other actors: an example is the timeslot in which the Executor will execute the experiment.

Figure 9 illustrates that the schema EECC (Executor Experiment

Configuration Concept), generated as a result of the specification given by the Experiment Proponent considering the options available as registered by the WebLab Registrar, is used to generate the ECEF (Experiment Configuration Executor Form) form, which is generated automatically by processing the EECC2FORM transformation specification. Once the Experiment Executor has successfully chosen all possible alternatives, a valid EECR (Execution Experiment Configuration and Reservation)

document is produced. As in the previous flows, our approach offers an alternative of reusing a previous specification, in this case by importing the IEECR (Imported Execution Experiment

Configuration and Reservation) document.

Figure 9. Document flow for reservation and complementing experiment parameters values

EECC schema: Executor Experiment Configuration Concept. ECEF: Experiment Configuration Executor Form. EECC2FORM:

transformation specification from EECC to ECEF form. EECR: Executor Experiment Configuration and Reservation. IEECR:

Imported Executor Experiment Configuration and Reservation. MEP: Manual Edition Process. MUX (multiplex): multiple-entry

selector. VC: Validation Check.

4. RELATED WORK This work is related to research involving XML transformations and the generation of Web applications.

The transformations of documents with XSLT, though efficient, demands important authoring effort given that the mapping involved in the transformation is mostly manual an, as such, error prone. Moreover, any change on the structure of the source document implies changes on the corresponding transformation specification, demanding efforts with respect to the maintenance of the XSLT documents.

Boukottaya et al. [8][9] discuss the matching problem in the context of structured document transformations. The authors identify two main problems related to schema matching relative to XSLT transformations: the first is related to scalability, resulting for the diversity of possible constructors (elements, attributes, etc.) in XML Schemas; the second results from the need of establishing semantic mappings. They contribute with a two-layer model and associated mappings: the Schema layer maps the schema constructors to a logical model which is then mapped to a Semantic layer which associates a conceptual meta-model to the logical model. In our current approach, the mapping underlying the transformations has been executed manually, and our XSLT specifications are used to generate document instances that are both presentation documents and XML Schemas. Considering the opportunity for applying our current approach to other domains, the automated support proposed by Boukottaya et al. [8][9] can be exploited to facilitate the design of the XSLT transformations we use.

Beaudoux [6] proposes an alternative approach for active document transformation based on rules associated with source and target DOM documents. The work focuses on demands for generating presentation documents from multiple sources, for multiple targets as well as source-to-target linking and bidirectional linking, and proposes the definition of two new DOM node types. So far, our work exploits a more traditional transformation approach, given that the several actors we support follow a specified workflow.

Some authors exploit transformations to tackle problems associated with the maintenance of XSLT specifications. Villard and Layaïda [25] proposes the use of incremental transformations focusing on the the target document: the aim is to modify only the portion of the document that demands modifications which implies, with respect to the transformation, that only the corresponding portions of the templates be applied. The XSLT transformations included in our implementation generate XML Schemas as well as presentation documents, and schema conformance operations are repeated when users do not provide appropriate configurations for the schemas to be generated. So far, we have not included optimization techniques because the size of the schemas, of the instances and of the transformations are small due to the underlying workflow-based processing adopted.

Our work is also related to efforts investigating the generation of web applications via XSLT transformations. Andrade et al. [3][4] propose a document-based approach to generate Web applications based on the application of successive models derived from separate design concerns: conceptual model (using XMI),

navigational model and presentation model. Similarly to their work, we use successive transformations to obtain presentation documents. A main difference is that, while they generate XSLT transformations on the fly, we generate XML Schemas. Another important difference is the interactive and iterative aspect of our approach.

A large number of XML editing systems is available (e.g. [2][5][7]). Those systems typically adopt a WYSIWYG user interface by hiding markups and are desktop systems. Our approach is related to Xforms [27], Forms-XML [16] and InfoPath [17].

XForms uses XML for data definition and XHTML for data display. XForms separates the data logic of a form from its presentation. In this way, the XForms data can be defined independently of how the end-user will interact with the application. With XForms, the rules for describing and validating data are expressed in XML. In XForms a model of the data needs to be predefined and in our approach we need create the model dynamically when the administrator sets the specific metadata for the TOOLARR. Another problem is that popular browsers do not implement XForms.

Forms-XML is a component constructed as an ActiveX control, which can be invoked by a Windows desktop application or an HTML/JavaScript client within the Internet Explorer browser. Forms-XML accepts four inputs: an XML schema, an XML document compliant with the XML schema, a user interface customization [16] (UIC) file, and a CSS style sheet [26]. Based on the schema and the UIC file, the component generates a hierarchy of HTML forms for the user to edit the input XML document. The presentation style of the generated HTML forms is specified by the given CSS style sheet. The use of ActiveX limits this approach to the browser Internet Explorer.

Like Forms-XML, InfoPath provide HTML form-based user interfaces for data-centric XML vocabularies. Unlike Forms-XML, InfoPath is a desktop application: it adopts the visual design approach to form development, being a form development system with an XML data model. However, its support for sophisticated XML vocabularies can be questionated it focuses on single forms.

5. FINAL REMARKS Considering the opportunity for specifying a standard way to describe a WebLab and to define general and specific experiment configuration and presets, we have designed the I-TOOLARR system.

Including XML Schemas and XSLT specifications, the I-TOOLARR system is used to support users in providing information so that laboratories can be accessed and controlled via the Web: from general metadata information to the specification of the corresponding experiments.

The approach proposed and presented in this paper can be used in contexts broader than the configuration of domain-independent experiments. We aim to extend the current implementation so that our document-based approach can be used for the configuration of any tool prior its integration into a specific environment.

The use of XML Schemas can be enhanced by the use of an ontology-based specification relative to laboratories in general and WebLabs in particular. Moreover, the use of the ontologies can also be exploited so that new definitions are automatically identified and made available. For instance, as administrators configure laboratories and experiments, new ontology components are automatically identified and used to extend the original ontology itself.

Regarding our current implementation, importing results from the experiments, once carried out by the Experiment Executors, to our document-based infrastructure demands bidirectional communication with the system controlling the laboratories. A natural alternative is the use of Web Services, as exploited by Yan et al. [29] [30], which we plan to investigate.

Acknowledgment. Our thanks to FAPESP for the financial

support to the TIDIA-Ae Project. We also acknowledge support

from FAPESP, CNPq and CAPES.

6. REFERENCES [1] A. M. Khamis, F. J. Rodriguez, and bl. A. Salichs, “Remote

interaction with mobile robots,” Autonomous Robot, vol. 15, no. 3, 2003, pp.267-281.

[2] Altova, XMLSPY. [Online]. Available: http://www.xmlspy.com/

[3] Andrade, A. R., Munson, E. V., and Pimentel, M. G. 2004. A document-based approach to the generation of web applications. In Proceedings of the 2004 ACM Symposium on Document Engineering (Milwaukee, Wisconsin, USA, October 28 - 30, 2004). DocEng '04. ACM Press, New York, NY, pp. 45-47.

[4] Andrade, A.R.; Munson, E.V.; Pimentel, M.G.C., "Engineering Web applications with XML and XSLT," WebMedia and LA-Web, 2004. Proceedings ,pp. 86- 93, 2004.

[5] Arbortext, Epic Editor. [Online]. Available: http://www.arbortext.com/

[6] Beaudoux, O. 2005. XML active transformation (eXAcT): transforming documents within interactive systems. In Proceedings of the 2005 ACM Symposium on Document Engineering (Bristol, United Kingdom, November 02 - 04, 2005). DocEng '05. ACM Press, New York, NY, pp. 146-148.

[7] Blast Radius, XMetal. [Online]. Available: http://www.softquad.com/

[8] Boukottaya, A. and Vanoirbeek, C. 2005. Schema matching for transforming structured documents. In Proceedings of the 2005 ACM Symposium on Document Engineering (Bristol, United Kingdom, November 02 - 04, 2005). DocEng '05. ACM Press, New York, NY, pp.101-110.

[9] Boukottaya, A., Vanoirbeek, C., Paganelli, F., and Khaled, O. A. 2004. Automating XML documents transformations: a conceptual modelling based approach. In Proceedings of the First Asian-Pacific Conference on Conceptual Modelling - Volume 31 (Dunedin, New Zealand). S. Hartmann and J. F. Roddick, Eds. ACM International Conference Proceeding

Series, vol. 59. Australian Computer Society, Darlinghurst, Australia, pp. 81-90.

[10] Brown, D.C; Cruz, I.F.; Finkel D.; Kinicki, R.E.; Wills, C.E. Experiences with the Webware, interfaces and networking experimental laboratory. SIGCSE '00: Proceedings of the thirty-first SIGCSE Technical Symposium on Computer Science Education, 2000, pp. 387-391.

[11] Casini, M., Prittichizzo, D., and Vicino, A., “The Automatic Control Telelab: A User-Friendly Interface for Distance Learning,” IEEE Transactions on Education, Vol. 46, No. 2, 2003, pp. 252–257.

[12] Casini, M.; Prattichizzo, D.; and Vicino, A. “The Automatic Control Telelab. A Web-based technology for distance learning,” IEEE Contr. Syst. Mag., vol. 24, no. 3, pp. 36–44, 2004.

[13] CUNY, “e-Lab.” [Online]. Available: http://www.mission-technology..com/nsfrobot/

[14] D. Ferreira, J. M.; Müller, “The MARVEL EU project: A social constructivist approach to remote experimentation”. In 1st Remote Engineering and Virtual Instrumentation International Symposium, Villach - Austria, 2004, 11p.

[15] Del Alamo, J. A., L. Brooks, C. McLean, J. Hardison, G. Mishuris, V. Chang V., and L. Hui. The MIT Microelectronics WebLab: A Web-Enabled Remote Laboratory for Microelectronic Device Characterization. 2002 World Congress on Networked Learning in a Global Environment, Berlin, Germany.

[16] Kuo, Y. S., Shih, N. C., Tseng, L., and Hu, H. 2005. Generating form-based user interfaces for XML vocabularies. In Proceedings of the 2005 ACM Symposium on Document Engineering (Bristol, United Kingdom, November 02 - 04, 2005). DocEng '05. ACM Press, New York, NY, pp. 58-60.

[17] Microsoft, Office InfoPath 2003, SP1. [Online]. Available: http://www.microsoft.com/office/infopath/prodinfo/default.mspx.

[18] MIT, “The Challenge of Building Internet Accessible Labs,” 2005. [Online]. Available: http://icampus.mit.edu/ilabs/

[19] Reske, D. Moussavi, Z. Engineering in Medicine and Biology, 2002. 24th Annual Conference and the Annual Fall Meeting of the Biomedical Engineering Society (EMBS/BMES Conference, 2002). vol 3, pp. 1847- 1848.

[20] Ross R.. J.; Boroni, C.M.; Goosey, F.W.; Grinder, M.; Wissenbach, P. WebLab! A universal and interactive teaching, learning, and laboratory environment for the World Wide Web, SIGCSE '97: Proceedings of the twenty-eighth SIGCSE Technical Symposium on Computer science education, 1997, pp. 199-203.

[21] RPI, “Automated Internet Measurement Laboratory.”[Online]. Available: http://nina.ecse.rpi.edu/shur/remote/

[22] TIDIA-AE, “TIDIA-AE Project Portal.” [Online]. Available: http://tidia-ae.incubadora.fapesp.br/portal

[23] UIU, “Bugscope.” [Online]. Available: http://bugscope.beckman.uiuc.edu/

[24] UTC, “Control System Lab.” [Online]. Available: http://chem.engr.utc.edu/Webres/Stations/controlslab.html

[25] Villard, L. and Layaïda, N. 2002. An incremental XSLT transformation processor for XML document manipulation. In Proceedings of the 11th international Conference on World Wide Web (Honolulu, Hawaii, USA, May 07 - 11, 2002). WWW '02. ACM Press, New York, NY, pp. 474-485.

[26] W3C, Cascading Style Sheets, Level 2, W3C Recommendation, May 12, 1998. [Online]. Available: http://www.w3.org/TR/REC-CSS2/

[27] XForms 1.0 (Second Edition). W3C Recommendation 14 March 2006. [Online]. Available: http://www.w3.org/TR/xforms/

[28] XML Schema 1.1 Part 2: Datatypes. [Online]. Available: http://www.w3.org/TR/xmlschema11-2/

[29] Yan, Y.; Liang, Y.; Du, X.; Saliah-Hassane, H., Ghorbani, A. Putting Labs Online with Web Services. IT Professional, March 2006, pp. 27-34.

[30] Yan, Y.; Liang, Y.; Du, X. Controlling Remote Instruments Using Web Services for Online Experiment Systems. IEEE International Conference on Web Services (ICWS'05), 2005, pp. 725-732.