2. The model must hide the complexities of both the underlying technology and the
integration questions popping up as soon as actual integration into an application or
Web server comes to mind.
3. The model must allow for flexible data structures to both be sent to the agents and be
received from the agents.
4. It must be possible to modify the data in both directions.
5. Standards should be used to implement the model transformation/executions.
To fulfill these requirements, we make the following decisions:
1. The model will be formulated in ???an XML-like syntax similar to HTML??? (see below).
This will allow current Web developers to easily grasp the concepts. As a side effect,
the model definitions for now will be included in the definitions for HTML pages.
The special tags defined to describe WASP models will be shown below.
2. The model for now will only fulfill the most basic requirements of a basic IO system.
Complex logic will be hidden in the underlying agents and processes. The model is
thus only concerned with retrieving data from some source and sending (other) data
to a sink (which provides the results as a response).
3. Technically we will assume that some kind of extension of the underlying server that
analyzes the HTML code before it is sent to the client, extracts the WASP-specific
definitions, processes them, and re-integrates the results of those definitions.
Pages:
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510