Copyright © 2001-2002 Boeing. This document is available under the W3C Document License, see the W3C Intellectual Rights Notices and Disclaimers for additional information.
This document describes the Simulation Reference Markup Language (SRML), a language for adding behavior to XML [1] documents. SRML is an XML application that can describe the behavior for distributed simulation models, and its runtime environment is software that is capable of executing those models. The goal of SRML is to enable simulations or other content to be served, received, and processed in a standard fashion using Internet technologies and the World Wide Web, just as HTML enables that functionality for text, and MathML [2] enables that functionality for mathematics. SRML combines XML and scripts to encode both the structure and behavior of all items comprising a simulation. A small number of SRML tags and pre-designated attributes are used to describe abstract items, while rich internal and external structures are further described and validated by the native rules of XML and simulation-specific schemas [3].
This document is intended primarily for those wanting to use of XML as a means for describing behavior in XML documents or executing computer simulations.
This document begins with background information on the representation and development of simulations in computers, the problems they pose, and the philosophy underlying the solutions SRML proposes. An SRML programmer's quick reference guide follows, along with a description of the runtime environment within a software engine known as a Simulation Reference Simulator. The document concludes with a language reference and a schema definition.
This NOTE was submitted to the World Wide Web Consortium (see Submission Request, W3C Staff Comment) on 2002-09-27 with the intention that the W3C use it as a basis for furthering the work. For a full list of all acknowledged Submissions, please see Acknowledged Submissions to W3C.
Inquiries from the public about this submission should be directed to steven.w.reichenthal@boeing.com. The forum most appropriate for discussion of SRML and related matters in the context of SRML is Boeing. The W3C forum most appropriate for discussing this submission is not defined.
This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.
A list of current W3C technical documents can be found at the Technical Reports page.
Simulation is a process that attempts to predict aspects of the behavior of some system by creating an approximate (mathematical) model of it. Computers provide an ideal environment for building simulations. Simulations have many uses, including the following:
In a broader sense, computing can be viewed as simulation [12] because computer programs resemble the domains to which they are applied. Thus, even though the traditional view of simulation is expressed in this document, SRML may be used to implement broad computing solutions.
Generally, simulation is a three-step process that follows the sequence: Model, Simulate, and Evaluate. The process involves several roles: Modeler, Domain Expert, Recipient/Decision maker. Modelers and domain experts build models using a tool known as a simulation development environment. This tool generates and stores a representation of the model that is fed into a simulation engine that manages objects, events, math, statistics and random numbers. The engine typically provides some kind of feedback about the simulation progress, as running a simulation may take more than a few seconds. Once the simulation has completed, modelers, domain experts, and decision makers evaluate the results and feed those results into the construction of a new model. Thus, simulation usually follows an ongoing iterative methodology.
A modeler who uses a general-purpose simulation development environment of any complexity is doing a form of programming, whether it is text-based or not. Because simulation involves programming, both have similar requirements. They both need to be low cost, easy to program, platform independent, reusable, standards-based, and graphics-based. Aside from general programming, simulations pose challenges of their own. For example, simulations typically need to represent large numbers of interrelated objects, and need to manipulate them at high speeds. Thus, unlike a traditional business program, a simulation may require lots of computing speed and memory. Due to the iterative process of simulation, modelers and other users need a way to easily repeat a simulation run with varying random number seeds and be able to combine the results. Likewise they need the ability to repeat simulation runs while systematically varying one or more parameters. Users also desire the ability to watch, freeze, reverse, and snapshot a simulation.
Additional challenges arise in simulations because they can have many characteristics:
The following list identifies some characteristics that make XML technologies particularly suitable and beneficial for simulations:
XML consists of elements that are specified using tags (words bracketed by '<' and '>'). Elements can have attributes (described by a name-value pairs), and can contain embedded elements:
<elementname1 attributename1='value1' attributename2='value2' ...>
<embedded-element1 ...>
...
</embedded-element1>
...
</elementname1>
These constructs form a structure for describing any kind of hierarchically related discrete data. An XML Schema permits a modeler to specify rules about element relationships and attributes that can be validated with software. The XML Document Object Model (DOM) [4] is an Application Programming Interface (API) that enables programming languages and scripts to load, validate, navigate, modify, and save XML structures with code. Software libraries and components for the DOM are freely available from several sources, including Microsoft. DOM software implements elements and attributes with linked Node objects. For example, the previous XML construct can be represented in the DOM as:
Node (NodeName='elementname1')
Attribute (BaseName='attribute1', NodeTypedValue='value1')
Attribute (BaseName='attribute2', NodeTypedValue='value2')
Node (BaseName='embedded-element1')
Use of plain XML does not imply semantic interpretation, presentation, or behavior of the data. Rather, schemas and higher-level specifications, such as Semantic-web for semantics, and XSLT [5] for presentation provide those. Typically behavior comes from other markup language like DHTML [6] and XHTML [7]. However, those languages couple presentation and behavior.
The XML domain specifies documents, elements, attributes, child elements and parent elements. The Simulation Reference domain specifies simulations, items, properties, sub-items, and locations. An SRML Simulator (or SR Simulator) creates simulations from documents, items from elements, properties from attributes, sub-items from child elements, and locations from parent elements. In addition to the things that correspond between the two domains, the SRML domain specifies item classes, behaviors, links, event classes, event sinks, events, and parameters.
SRML to XML mapping:
| SRML Domain | Implicit | XML Domain |
|---|---|---|
| Simulations, Simulation | Y | Document |
| Item | Y | Element |
| Property | Y | Attribute |
| Sub Item | Y | Child Element |
| Items | Y | childNodes in the DOM |
| Location | Y | Parent Element, parentNode in the DOM |
| ItemClass | N | (Roughly corresponds to a Schema definition) |
| Script (Behavior) | N | - |
| Links, Link | N | IDREF(s) and XPath |
| EventClass | N | - |
| EventSink | N | - |
| Events | N | - |
| ItemEvent | N | - |
| Parameter | Y | - |
The Simulation Reference Markup Language is designed according to the following goals:
This section defines the elements of the Simulation Reference Markup Language (SRML). SRML defines a small number of elements and attributes for describing abstract structures, properties, and behaviors to support specific domains under simulation. Thus, SRML is typically used in conjunction with domain-specific schemas that add structural rules and data types to elements and attributes.
<!ELEMENT Simulations (#PCDATA | Script | Simulation | ItemClass | ANY)*> <!ATTLIST Simulations ANY>
The Simulations element is the root of a group of simulations specified in the same document. It contains zero or more Script elements as children. Each Script child element contributes to the overall behavior of the Simulations item corresponding to the element. The Simulations element may also contain zero or more Simulation elements that define the individual simulations in the group. It may also contain zero or more ItemClass elements that define the structure and behavior for classes of simulation items that span the group. The Simulations element allows for the specification of any attributes. An SRML simulation does not require a Simulations element.
Example:
<Simulations>
<Simulation Name='Simulation1'>
...
</Simulation>
<Simulation Name='Simulation2'>
...
</Simulation>
</Simulations>
<!ELEMENT Simulation (#PCDATA | Script | ItemClass | Item | EventClass | ANY)*, Events>
<!ATTLIST Simulation Source CDATA #IMPLIED
ANY>
The Simulation element is the root of a simulation. It contains zero or more Script elements as children. Each Script child element contributes collectively to the behavior of the Simulation item corresponding to the Simulation element, and thus specifies the main simulation behavior - or "main script". The Simulation element may also contain zero or more ItemClass elements that define the structure and behavior for classes of simulation items. In addition, zero or more Item elements may specify individual item instances. The Simulation element allows for the specification of any attributes. An SRML simulation does not require a Simulation element.
Example:
<Simulation>
<Script Type='text/javascript'>
...
</Script>
<ItemClass Name='Vehicle'>
...
</ItemClass>
<Vehicle Quantity='100'/>
</Simulation>
<!ELEMENT Script (#PCDATA)>
<!ATTLIST Script Type CDATA 'text/javascript'
Source CDATA #IMPLIED
Language CDATA #IMPLIED>
The Script element, when enclosed within any non-Script element defines the behavior for the item corresponding to the enclosing element. Any number of Script elements may exist within the enclosing element, each of which may contain functions, procedures or variables that override the previous script. An individual Script element may specify either Type or Language, but not both.
Example:
<Script Type='text/javascript'> ... </Script>
<!ELEMENT ItemClasses (#PCDATA | ItemClass | ANY)*>
<!ATTLIST ItemClasses
Source CDATA #IMPLIED
ANY>
The ItemClasses element provides a means for grouping item classes. It contains zero or more ItemClass elements as children. The ItemClasses element allows for the specification of any attributes. Any particular ItemClass element is not required to be specified in an ItemClasses element and an SRML simulation does not require an ItemClasses element. In all other respects, the same semantics apply to the ItemClasses element as apply to the Item element.
Example:
<ItemClasses>
<ItemClass Name='Vehicle'>
...
</ItemClass>
<ItemClass Name='Weapon'>
...
</ItemClass>
</ItemClasses>
<!ELEMENT ItemClass (#PCDATA | Script | Item | ANY)*>
<!ATTLIST ItemClass Name ID #REQUIRED
SuperClasses IDREFS #IMPLIED
Source CDATA #IMPLIED
ANY>
The ItemClass element defines a class of items that all have the same properties, structure, and behavior. It contains zero or more Script elements as children. Each Script child element contributes collectively to the behavior of the item corresponding to the ItemClass element. An ItemClass element may include a prototype Item child element that specifies the properties, structure, and behavior for item instances. The prototype Item elements do not need to be named 'Item'. Rather, it should have a name that matches the Name attribute of the ItemClass element. An ItemClass element may appear anywhere in a document, and does not need to precede the items it specifies.
Example:
<ItemClass Name='Vehicle' SuperClasses='Transportation'>
<Vehicle HP='400'>
...
</Vehicle>
</ItemClass>
<!ELEMENT Item (#PCDATA | Script | Item | Link | Links | EventSink | ANY)*, Events>
<!ATTLIST Item ItemClass IDREF #IMPLIED
Quantity CDATA #IMPLIED
Name CDATA #IMPLIED
LocationFixed CDATA #IMPLIED
Source CDATA #IMPLIED
ItemID CDATA #IMPLIED
ANY>
The Item element declares an instance of a simulation item. It contains zero or more Script elements as children. Each Script child element contributes collectively to the behavior of the item corresponding to the Item element. An Item element in a document may contain zero or more sub-item elements as children, along with zero or more Link and Links elements. The Item element is a reference element, and thus does not need to be specified by name. Instead, an element from any namespace, other than one with a name that begins with the case insensitive sequence "xml", derives an item. Therefore the following two item declarations are equivalent in the SRML domain:
<Item ItemClass='Vehicle'/> <Vehicle/>
The latter declaration is preferred since it better promotes the use of domain-specific schemas.
Example:
<Vehicle Quantity='100' Name='Explorer'>
<Script Type='text/javascript'>
...
</Script>
</Vehicle>
<!ELEMENT Link>
<!ATTLIST Link Name CDATA #IMPLIED
Target CDATA #REQUIRED
Enabled CDATA 'True'
WithPropertiesChanged CDATA #IMPLIED
WithLocationChanged CDATA #IMPLIED
WithEventsReceived CDATA #IMPLIED
WithItemLifetime CDATA #IMPLIED>
The Link element specifies a link from one item (the owner) to another. The Link element derives a property of the enclosing item that directly refers to the target object. A physical link between two items may also be using an attribute of type IDREF in the enclosing item.
Example:
<Vehicle VIN='123'>
<Script Type='text/javascript'>
<![CDATA[
var Y = Dealer.DealerID;
]]>
</Script>
<Link Dealer='//*[@DealerID="333"]'/>
</Vehicle>
On activation, the link's owner will receive the event in a script method with the following signature: Name_PropertyChanged(objItem, varNewValue)
On activation, the link's owner will receive the event in a script method with the following signature: Name_LocationChanged(objItem)
On activation, the link's owner will receive the event in a script method with the following signature: Name_EventName(objTarget, parameter1, ...)
On activation, the link's owner will receive the event in a script method with the following signature: Name_Destroyed(strItemID)
Examples:
See EventSink Element
<!ELEMENT Links (Link)*> <!ATTLIST Links Name CDATA #IMPLIED>
The Links element specifies a collection of links. This element may contain zero or more Link elements as children. A collection of physical links between two items may also be specified using an attribute of type IDREFS in the enclosing item.
Example:
<Vehicle VIN='123'>
<Script Type='text/javascript'>
<![CDATA[
var X = Owners[1].OwnerID;
]]>
</Script>
<Links Name='Owners'>
<Link Target='//*[@OwnerID="111"]'/>
<Link Target='//*[@OwnerID="222"]'/>
</Links>
</Vehicle>
<!ELEMENT EventClasses (#PCDATA | EventClass | ANY)*>
<!ATTLIST EventClasses
Source CDATA #IMPLIED
ANY>
The EventClasses element provides a means for grouping Event classes. It contains zero or more EventClass elements as children. The EventClasses element allows for the specification of any attributes. Any particular EventClass element is not required to be specified in an EventClasses element and an SRML simulation does not require an EventClasses element. In all other respects, the same semantics apply to the EventClasses element as apply to the Item element.
Example:
<EventClasses>
<EventClass Name='VehicleEvent'>
...
</EventClass>
<EventClass Name='WeaponFire'>
...
</EventClass>
</EventClasses>
<!ELEMENT EventClass (#PCDATA | Script)*>
<!ATTLIST EventClass Name ID #REQUIRED
SuperClasses IDREFS #IMPLIED
ANY>
The EventClass element specifies a class of events that span a simulation or simulations. This class designates the name of an event, which may be the specialization of another event class, or be further specialized by a sub-event class. Event classes are not required.
Example:
<EventClass Name='VehicleEvent'/> <EventClass Name='VehicleStarted' SuperClasses='VehicleEvent'/> <EventClass Name='CarStarted' SuperClasses='VehicleStarted'/> <EventClass Name='TruckStarted' SuperClasses='VehicleStarted'/> <EventClass Name='VehicleCrashed' SuperClasses='VehicleEvent'/>
<!ELEMENT EventSink #PCDATA>
<!ATTLIST EventSink Name CDATA #REQUIRED
EventClasses CDATA #IMPLIED
Enabled CDATA 'True'
ItemClasses CDATA #IMPLIED
WithPropertiesChanged CDATA #IMPLIED
WithLocationChanged CDATA #IMPLIED
WithItemLifetime CDATA #IMPLIED>
The EventSink element specifies an event sink at the enclosing item. An event sink is a construct that allows a simulation item to receive event information either directly or indirectly from other simulation items based on events meeting certain criteria. For example, an item may have an event sink that receives all events within a certain event class or one of its sub-classes. In another situation, an item can receive all changes of a certain property belonging to an item class or one of its sub-classes. Thus, the event sink listens to two disjoint types of events: those based on an ItemClass and those based on EventClasses.
On activation, the link's owner will receive the event in a script method with the following signature: Name_EventClassName(objTarget, parameter1, ...)
On activation, the link's owner will receive the event in a script method with the following signature: Name_PropertyChanged(objItem, varNewValue)
On activation, the link's owner will receive the event in a script method with the following signature: Name_LocationChanged(objItem)
On activation, the link's owner will receive the event in a script method with the following signature: Name_ItemCreated(strItemID) or Name_ItemDestroyed(strItemID)
Examples:
PostEvent(Simulation, "CarStarted", this) PostEvent(objCar, "CarStarted", this) objCar.Location = Fwy55 objCar.Speed = 65
<EventSink
Name='MySink1'
EventClasses='VehicleStarted'
/>
<EventSink
Name='MySink2'
ItemClass='Vehicle'
WithPropertiesChanged='Speed'
WithLocationChanged='True'
WithItemLifetime='True'
WithEventsReceived='VehicleStarted VehicleCrashed'
/>
MySink1_VehicleStarted(objVehicle, a)
MySink2_SpeedChanged(objVehicle, varNewValue)
MySink2_VehicleStarted(objVehicle, a)
MySink2_LocationChanged(objVehicle)
<!ELEMENT Events (ItemEvent)*>
The Events element specifies a collection of events scheduled or posted for an item. This element includes zero or more ItemEvent elements.
<!ELEMENT ItemEvent (Parameter | ANY)*>
<!ATTLIST ItemEvent EventID CDATA #IMPLIED
Name CDATA #REQUIRED
Time CDATA #IMPLIED
Format CDATA 'Method'
Cascade CDATA 'CascadeNone'
Source CDATA #IMPLIED
Cancel CDATA #IMPLIED>
The ItemEvent element specifies the information about an event scheduled or posted for an item to receive. This element includes zero or more Parameter events as children.
<!ELEMENT Parameter #PCDATA>
The Parameter element specifies a parameter of an item event. This is a reference element and need not be specified by name, because any child element of an ItemEvent element is considered a parameter.
Example:
<?SRML TargetEngine='SR_Simulator.Simulation' TargetVersion='1.0' ?>
The SRML processing instruction specifies parameters that govern the processing behavior of an SR Simulator.
This is a brief tutorial to familiarize you with the language and semantics of SRML. As a modeler, you would build XML models and execute them in an SRML Simulator (or SR Simulator). An SR Simulator reads XML input that conforms to the SRML Schema, builds script-based items corresponding to each of the elements and executes events scheduled by those items. An SRML modeling tool is a software program that allows you to create and edit SRML simulations.
SRML organizes XML in a way that makes it practical to represent:
SRML, like XML, does not specify any data presentation. Other markup languages and tools like DHTML, XHTML, Java, Microsoft Office and Visio satisfy that need. XML also does not specify the use of any particular simulation development tools.
The things you describe when modeling in SRML are referred to as items. An item can represent a physical thing, such as a piece of equipment, or a person, or an entire system of other items. An item may also represent a process or a step in a process. Items can have properties. For example, a piece of equipment might have a 'serial number' property and a process might have 'duration' property. SRML provides a natural way to express items, their properties, and complex item relationships, using the grammar of XML with a small set of pre-defined elements and attributes that have specific meanings and rules. The general structure of a simulation in SRML looks like this:
<Simulation>
<!-- Main Script - the following element defines the behavior for the entire simulation -->
<Script Type='script-language' Source='optional-script-source'>
code
</Script>
<!-- The following element defines an item class -->
<ItemClass Name='itemclassname1' SuperClasses='itemclassnameX ...' Source='optional-source' property1='value1' ...>
<!-- The following element defines the behavior for the class; not individual instances -->
<Script Type='script-language' Source='optional-script-source'>
code
</Script>
<!-- The following element defines the prototype for the instances -->
<itemclassname1 property1='value1' ...>
<!-- The following element defines the behavior for the instances -->
<Script Type='script-language' Source='optional-script-source'>
code
</Script>
</itemclassname1>
</ItemClass>
<ItemClass Name='itemclassname2' ...>
...
</ItemClass>
<!-- The following element defines an instance of an item class -->
<itemclassnameA Name='itemname1' Quantity='number' Source='optional-source' property1='value1' ...>
<Link Name='linkname1' Target='query' />
<Link ... />
<Links Name='linksname1'>
<Link Name='linkname2' Target='query' />
...
</Links>
<Script Type='script-language' Source='optional-script-source'>
code
</Script>
<itemclassnameB Name='itemname2'>
...
</itemclassnameB>
</itemclassnameA>
<itemclassnameC ...>
...
</itemclassnameC>
</Simulation>
Items and properties correspond to elements and attributes in the XML. Thus, you won't find a specific element called 'item' in the previous construct because items are derived from the elements, and properties are derived from the attributes. With the exception of a few pre-defined element names, such as ItemClass, SRML uses the elements and attribute names that you define. This makes it possible to create a domain-specific XML schema to validate the structure of a system and to provide data types for the attributes [8]. A domain-specific schema works in conjunction with the SRML schema when using XML namespaces [9].
The following illustration shows a simplified conceptual model of an item. Internally an item has a unique system-generated ItemID and a script. It has an association with a DOM node-from the element. An item can both serve as a location for other items, and belong at a location along with other items. It can have links to other items, and be a target for a link. Also, it can belong to an item class, which in turn can have super-classes. The properties of an item are derived directly from DOM attributes. The behavior of an item is defined in its script or may be defined externally. The ItemClass element allows you to generalize groups of common items, yet an item does not need to have a corresponding ItemClass.
The following example shows the definition of a Vehicle element and Name attribute in XML, which corresponds to a Vehicle item that has a Name property with a value of 'Challenger', and a VIN of 'N3462983':
<Vehicle Name='Challenger' VIN='N3462983'/>
You define an item's behavior inside a Script element using a language such as JavaScript or VBScript, and specifying the Type attribute as either 'text/javascript', 'text/vbscript', or any other simulator-supported language. Refer to the following example:
<Vehicle ID='AirforceOne' Running='1'>
<Script Type='text/javascript'>
<![CDATA[
var Occupied=0;
function turnOn()
{
Running=1;
}
function turnOff()
{
Running=0;
}
]]>
</Script>
</Vehicle>
In general, you can think of an item as an object that is defined with an XML element and a script. The Vehicle item is given a unique system-wide identifier (an ID property has global semantics) and a Running property with an initial value of '1'. The script directly accesses DOM attributes to obtain properties. It can also define properties that don't have corresponding attributes by declaring public variables-as in the Operable variable. Also note that the item's behavior comes by way of user-defined functions, such as 'turnOn', and 'turnOff'.
Because the script defines AirForceOne as having a global identifier, the following examples of code may be used anywhere in the model:
AirForceOne.Occupied=1; AirForceOne.turnOn(); X=AirForceOne.Running; AirForceOne.turnOff();
A small number of intrinsic properties apply to all items. For example, every item has a Location property that refers to its current location. In the following example, the sensor identified by 'TSM5865' has its location set to the controller identified by 'TS293847'. Most of the time an item's location refers to another item. However, sometimes an item's location can be 'Nothing' or 'undefined', which means that it either does not exist in the model or is at the top of the location tree. Each item also has an Items collection that holds references to all of the items it contains. In the example, the controller sends queryStatus to its items when it is asked to poll. When a sensor's queryStatus method is invoked, it invokes the receive method at its location.
Controller.xml:
<Simulation Name='ControllerSimulation'>
<Controller Name='TS293847' Operable='1' Pings='0' Health='1'>
<Script Type='text/javascript'>
<![CDATA[
function poll()
{
Items(1).queryStatus();
Items(2).queryStatus();
}
function receive(Name, Value)
{
Health=math.min(Health, Value);
Pings++;
}
]]>
</Script>
<Sensor Name='TSM5865' Quantity='2'>
<Script Type='text/javascript'>
<![CDATA[
function queryStatus()
{
Location.receive(Name, Random());
}
]]>
</Script>
</Sensor>
</Controller>
</Simulation>
A situation may arise when a large quantity of a particular item or structure needs to occur. Within any element, you can provide the Quantity attribute, which instructs an SR Simulator to duplicate the element and its contents. For example, the following structure defines a total of 240 eggs, in a total of 20 egg cartons in two refrigerators.
<Refrigerator Quantity='2'>
<EggCarton Quantity='10'>
<Egg Quantity='12' />
</EggCarton>
</Refrigerator>
XML provides an ideal structure for describing hierarchical containment relationships; however, situations may arise when items at various locations in a simulation need to have non-hierarchical connections to other items. Therefore SRML provides two linking mechanisms. The first involves using the Link element where you provide the name and an XPath [10] expression to identify the target. The second mechanism uses the Links element where you provide a name and supply inner links. When you use a schema and provide attributes of type IDREF or IDREFS [11], SRML treats them in the same way it treats links.
Items have other built-in properties besides the Location property and Items collection. When the SR Simulator initially creates an item, it automatically assigns a unique numeric value to the item's 'ItemID' property. You can use this property to uniquely identify the item in the presence or absence of an explicit ID attribute. Items also have a language-neutral 'Self' property that refers to the particular item instance in which a script is running. However, the traditional 'Me' (VBScript) and 'this' (JavaScript) keywords serve the same purpose. An item's Events collection contains references to all the events scheduled or posted to that item. This makes it easy at runtime to find and possibly alter previously scheduled events. As a simulation runs, the scripts operate directly on the underlying DOM nodes as they alter item properties and locations. Therefore each item has a Node property that returns its corresponding node. In addition, each item also contains a reference to its item class via its ItemClass property. You can add shared properties and behavior to a specific item class in the same way you add them to regular items.
The static structure of a model represents interconnected items at a point of time. As a simulation progresses, you may need to change an item's location. To do this, you simply assign its location property to a different item. For example, the following code in JavaScript changes Vehicle99's location to Alaska. Whenever an item's location is changed, the simulator will notify its host by raising the ItemLocationChanged event, and passing the item along with its previous location.
Vehicle99.Location = Alaska
Some items, such as geographical locations, may have their locations fixed for an entire simulation. When these items have unique names within their containing locations, such as California within United States, you can make them directly accessible by specifying LocationFixed='True' attribute. Refer to the following example:
Sites.xml:
<Location ID='World' LocationFixed='True'>
<Location Name='USA' LocationFixed='True'>
<Location Name='California' LocationFixed='True'>
<Location Name='Anaheim' LocationFixed='True'>
<Vehicle Name='Truck' Quantity='100' />
</Location>
</Location>
</Location>
</Location>
Somewhere in a script, you can address the first Truck in Anaheim within the World by the following syntax:
World.USA.California.Anaheim.Items(1);
You may also need to find items that meet certain criteria. To do so, simply provide an XPath expression to the FindItems function and it will return a collection of items that were found. For example, this code will set the objController variable to the first item found in a location that has its name set to Controller:
objController=FindItems("//Controller[@Name='TS293847']")(1);
Typically the items we model correspond to physical things, which include people, the weather, the ocean, the planets, mechanical devices and electronic circuits. Items such as these may both send and receive stimuli. The SRML runtime environment provides four procedures for sending synchronous, asynchronous and scheduled events among objects. The procedures are SendEvent, PostEvent, ScheduleEvent, and BroadcastEvent. Each of these procedures takes a target object, an event string, and any number of parameters. SendEvent sends the specified event immediately to the target object. PostEvent sends the event asynchronously to the target. ScheduleEvent takes a date-time parameter and sends the event at the specified time. This procedure returns an event identifier that uniquely identifies the event. BroadcastEvent can either sent, post, or schedule an event to cascade up or down an item hierarchy. You can prevent any particular scheduled event from occurring by calling RetractEvent and passing the event identifier. Use an item's Events property to identify the events scheduled for a particular item.
In a typical discrete-event simulation, a host of items will generate events autonomously. Since these items are linked to other items, communication proceeds naturally. However, the need typically arises for the simulation to generate metrics such as a count of event of a certain type over a period of time, or perhaps a trace of those same events. In other cases, the course of the simulation may need to change as the result of an event. By placing a Script element directly inside the Simulation object, you create a 'main script' that can intercept every event in the simulation immediately after it occurs. The main script is purely optional. In the next example, the main script receives the 'failed' and 'repaired' events of the Motor item, after the motor has received them.
Motor1.xml:
<Simulation>
<Script Type='text/javascript'>
<![CDATA[
var nFailures = 0;
var nRepairs = 0;
function Motor_failed(objLRU)
{
nFailures++;
}
function Motor_repaired(objLRU)
{
nRepairs++;
}
]]>
</Script>
<Motor ID='MO293847' Operable='1'>
<Script Type='text/javascript'>
<![CDATA[
ScheduleEvent(this, "failed", DateAdd("h", Random()*100, CurrentTime));
function failed()
{
Operable=0;
ScheduleEvent(this, "repaired", DateAdd("h", Random()*8, CurrentTime));
}
function repaired()
{
Operable=1;
ScheduleEvent(this, "failed", DateAdd("h", Random()*100, CurrentTime));
}
]]>
</Script>
</Motor>
</Simulation>
While SRML allows you to provide specific attributes and behavior for individual items, it also provides a generalization mechanism that allows you to create classes of items. An item class is analogous to class in object-oriented terms, in that it allows you to describe the attributes and behavior for its instances while also providing a type of inheritance. You can specify any number of item classes in a model by using an ItemClass element and specifying a unique Name. Within the class you also provide an instance prototype by embedding an element with a tag name that matches the Name attribute of the item class. This prototype can have attributes with default values and data types validated by an XML schema. Refer to the general form of an ItemClass as shown:
<ItemClass Name='itemclassname1' SuperClasses='itemclass1 itemclass2...' property1='value1' ...>
<!-- The following element defines the behavior for the class; not individual instances -->
<Script Type='script-language' Source='optional-script-source'>
code
</Script>
<!-- The following element defines the prototype for the instances -->
<itemclassname1 property1='value1' ...>
<!-- The following element defines the behavior for the instances -->
<Script Type='script-language' Source='optional-script-source'>
code
</Script>
</itemclassname1>
</ItemClass>
The highlighted area above indicates the prototype item, and the bold text shows the correspondence between the name of the prototype and the name of the item class. The specific example below, which also highlights the prototype item, demonstrates the definition of an item class called Counter. Each of the ten instances created from this Counter class will have a method called Increment and will have their own Count value. As an item itself, the ItemClass can also have properties and behavior that will be shared by the instances. The example defines an Instances property for the class that keeps track of the number of individual Counter instances. Any of the Counter instances can access its item class, through its intrinsic ItemClass property. Notice how the item accesses the Instances property in its item class in the code. In the note below, the code within the instance is directly updating the Instances value of the item class.
Counter.xml
<Simulation>
<ItemClass Name='Counter' Instances='0'>
<Counter Count='0'>
<Script Type='text/javascript'>
<![CDATA[
ItemClass.Instances++; // Note: Increment the item class's value.
function Increment()
{
Count++;
}
]]>
</Script>
</Counter>
</ItemClass>
<Counter Quantity='10' />
</Simulation>
Sometimes a common set of properties and behaviors apply to more than one item class. In this situation you have the opportunity to create a more general item class from which other more specific classes can inherit. Therefore, SRML provides a capability found in traditional object-oriented languages for defining classes at various levels of generalization. The mechanism in SRML provides polymorphism, multiple-inheritance, and overriding in both item class instances and the item class itself. In the example below, a Motor has two more general super-classes: Asset and Operates. You use the SuperClasses attribute to specify the list of named item classes in descending priority.
Motor4.xml:
<Simulation>
<Script Type='text/javascript'>
<![CDATA[
var nFailures = 0;
var nRepairs = 0;
function Motor_failed(objLRU)
{
nFailures++;
}
function Motor_repaired(objLRU)
{
nRepairs++;
}
]]>
</Script>
<ItemClass Name='Asset' Count='0'>
<Asset Operable='1'>
<Script Type='text/javascript'>
<![CDATA[
ScheduleEvent(this, "failed", DateAdd("h", Random()*100, CurrentTime));
function failed()
{
Operable=0;
ScheduleEvent(this, "repaired", DateAdd("h", Random()*8, CurrentTime));
}
function repaired()
{
Operable=1;
ScheduleEvent(this, "failed", DateAdd("h", Random()*100, CurrentTime));
}
]]>
</Script>
</Asset>
</ItemClass>
<ItemClass Name='Operates'>
<Operates Running='1'>
<Script Type='text/javascript'>
<![CDATA[
function turnOn()
{
Running=1;
}
function turnOff()
{
Running =0;
}
]]>
</Script>
</Operates>
</ItemClass>
<ItemClass Name='Motor' SuperClasses='Asset Operates' />
<Motor Quantity='10' />
</Simulation>
With the inherent modularity provided by XML, a single document may suffice for representing a large simulation. Many simulated items may take similar forms, and thus the mechanism of item classes provides the integration of common behavior. However, managing a single monolithic XML document does not work well when the pieces are developed independently, or when they need to be reused. External scripts provide a simple way to detach the behavior from the structure, thus allowing code reuse at the cost of some encapsulation. These scripts are specified by adding a Source attribute to a Script element. For example:
<Script Type='text/javascript' Source='Vehicle.js'/>
The entire behavior of an item or item class can thus be specified separately. The reason that encapsulation is slightly compromised is because the structural aspects of the item, being in XML, have been separated from the behavioral aspect, which is in a separate script. A more sophisticated technique known as embedded externals, allows portions of one simulation model to be extracted from another. This preserves encapsulation at the potential cost of a larger runtime footprint. You can specify an embedded external in several ways:
<Vehicle Source='http://srml.boeing.com/Vehicle.xml'/> <ItemClass Name='Vehicle' Source='file:///Vehicle.xml'/> <Vehicle Source='progid://simserver/VehicleComponent.Tank'/>
In the first case, the vehicle is defined completely in the XML document: Vehicle.XML, which is similar to creating an instance from an external item class-many such identical vehicles can be added to the simulation model using the same source file. In the second case, the item class defined in the external file is included in the current model, thus making it available for instancing or sub-classing. The third case shows how separately compiled component-based objects, known as external items, are plugged into the simulation. External items coexist with items in a simulation model, and also provide the capability for entire simulation models to be connected together using interoperability layers such as CORBA, COM, and HLA.
The SRML runtime environment is a collection of software objects that can read SRML input, build and manage the corresponding simulation items, connect those items together, and provide an event-driven mechanism for items to communicate. It also provides simulation support in the form of a random number generator, some simulation primitives (such as time averages and data structures), math functions, statistics functions, and the ability to generate outputs as defined by the model.
Simulations can run in many environments. For example, a simulation may run as part of a web page, as part of a spreadsheet, or embedded in a custom application. A single software component can support all of these environments. Such a component for SRML is known as a Simulation Reference Simulator (SR Simulator). A modeler can choose any host environment that is capable of both creating a Simulation object and using its interface. Possible hosts include Microsoft Internet Explorer, Microsoft Office applications, Microsoft Visual Basic, and Java. The following diagram shows a simplified view of how a Simulation object functions within its external environment.
An SR Simulator provides a class of Simulation objects. Each Simulation object encapsulates a simulation instance (or run), and is primarily responsible for providing the runtime environment. Since a Simulation is an object that embodies a particular execution of a simulation, many simultaneous simulations can exist on the same computer, or distributed across a network as a client or server. This next diagram shows the internal architecture of an SR Simulator and its associated environment.
The simulation loading process begins when a calling procedure invokes the Load method of a Simulation object and passes the location of the XML. At that point, the simulation calls upon an XML parser to build a validated DOM tree from the specified input. If successful, it then traverses the DOM tree and creates items from the nodes, attributes, links, and scripts they contain. Code within an item's script that appears outside a function or procedure gets invoked as the item is created. Given that some items are loaded before others, this outer code has limited access to other items. Specifically, the code can only access the item's Location property, its ItemClass property, any related super-classes, and the Simulation object. Its sub-items, links, and any global items can't be accessed until after the load is complete. If items require further initialization the modeler can broadcast a downward event from the root that invokes a specified initialization method. When loading has completed, the simulation is ready to begin process events, and the Simulation object is configured according to the following object model:
An SR Simulator loads SRML based on the following rules:
Once the simulation has been loaded, the Simulation object can execute the model as individual steps (using DoNextEvent), or as a single run (using the Run method). In either case, the Simulation object makes every event available to the host by either generating an EventOccurred event or by invoking the method in the host. The example code below shows how to run an SR Simulator and Simulation from HTML in a web browser host:
<html>
<head>
<title>Simulation Demonstration</title>
<object id="Simulation" classid="clsid:92BFC2E6-A248-449D-8537-E5D7A2CC64FE">
</object>
<script type="text/javascript">
function RunSimulation()
{
Simulation.CurrentTime = new Date ("1/1/2001").getVarDate ();
Simulation.EndTime = new Date ("1/2/2001").getVarDate ();
Simulation.Load (document.location.href + "/../Planes.xml");
Simulation.EventFlags = -1;
Simulation.RandomizeSeed ();
Simulation.Run ();
}
</script>
<script for=Simulation event="EventOccurred(objEvent)" type="text/javascript">
document.body.appendChild (document.createElement ("<P>"));
var objText = document.createTextNode (objEvent.Time + " " + objEvent.Target + objEvent.Target.ItemID + " " + objEvent.Name);
document.body.appendChild (objText);
</script>
</head>
<body>
<button onclick="RunSimulation()" type="text/javascript">Run Simulation</button>
</body>
</html>
| Part | Type | Applies | Description |
|---|---|---|---|
| EventClass | Element | Globally | Specifies a class of events that span a simulation or simulations. |
| Events | Element | Items | Specifies a collection of events scheduled or posted for an item. |
| EventSink | Element | Globally | Specifies a name and filter for events to be received by an item simulation. |
| Item | Element | Globally | Specifies an item. This is implied by elements in a domain-specific schema and need not be specified. |
| ItemClass | Element | Globally | Specifies a class of items, which all have a similar structure and behavior. |
| ItemClasses | Element | Globally | Specifies a group of item classes. |
| ItemEvent | Element | Events | Specifies the information about an event that has been scheduled or posted to an item. |
| JavaScript or text/javascript | Value | Script Language or Type | Specifies that the script language for an item is JavaScript. |
| Link | Element | Items | Specifies a link (object reference) to another Item. |
| Links | Element | Items | Specifies a collection of individual links. |
| LocationFixed | Attribute | Items | Specifies that an item is fixed within its location. This makes the item directly accessible to the location through either its ID or its Name whichever takes precedence. If two items have the same ID or name, the last one will become the item that is directly accessible. For example, if "itemname" is location fixed, then it can be accessed through location.itemname. |
| Name | Attribute | Items, ItemClasses | Designates the name for the Item or ItemClass. Name is required for an ItemClass, but not for an Item. |
| Parameter | Element | ItemEvent | Specifies an individual event parameter. |
| Quantity | Attribute | Items | Specifies the number of items to be constructed at the enclosing location. |
| Script | Attribute | Items, ItemClasses | Specifies the script, which defines the state and behavior for items. |
| Simulation | Element | Globally | Specifies an individual simulation. |
| Simulations | Element | Globally | Specifies a group of simulations. |
| Source | Attribute | Globally | Specifies the location of a document or object class that provides an external source of structure and/or behavior for an item. |
| SuperClasses | Attribute | ItemClass | Specifies an ordered sequence of ItemClasses or EventClasses that provide default structure and behavior for the ItemClass or EventClass respectively. Entries specified to the left of other entries have higher priority. |
| Target | Attribute | Link | Specifies the target object of the link. |
| Type | Attribute | Script | Specifies the language that the script uses. The Language attribute is also allowed; however, only one needs to be specified. |
| VBScript or text/vbscript | Value | Script Language or Type | Specifies that the script language is VBScript. |
| Part | Type | Applies | Description |
|---|---|---|---|
| ItemID | Attribute | Item | Returns the unique identifier assigned to the item by the simulation when it was created. |
| Events | Collection | Item | Returns the events currently scheduled for an item. |
| ItemClass | Attribute | Item | Returns the ItemClass of the item. |
| Items | Collection | Item | Refers to the sub items of the current item. |
| Location | Attribute | Item | Refers to another item that represents the current location of the item. |
| Node | Attribute | Item | Returns the XML DOM node corresponding to the item. |
| Self | Attribute | Item | Returns a reference to the current item. In JavaScript, the keyword 'this' may also be used. In VBScript, the keyword 'Me' may also be used. |
| Part | Type | Applies | Description |
|---|---|---|---|
| Abort | Method | Simulation | Aborts the running simulation. |
| BroadcastEvent | Method | Simulation | Sends, Posts, or Schedules an event to occur and cascade either upward or downward starting at a given item. |
| CreateItems | Method | Simulation | Creates a specified number of items at a particular location, based on a prototype item. |
| CreateTimeAverage | Method | Simulation | Returns a newly created TimeAverage object. |
| CurrentTime | Property | Simulation | Sets or returns the simulation's current time. |
| CurrentEvent | Property | Simulation | Returns the most recently executed event that was either posted or scheduled. |
| DateAdd | Method | Simulation | Returns the result of adding an interval number to a date. |
| DateDiff | Method | Simulation | Returns an interval difference between two dates. |
| DestroyItem | Method | Simulation | Destroys an item. |
| Document | Property | Simulation | Returns or sets the XML DOM document object. |
| DoNextEvent | Method | Simulation | Sends the next scheduled or posted event to its target. |
| EndTime | Property | Simulation | Sets or returns the end time of the simulation. |
| Error | Property | Simulation | Returns an object that contains information about the last error. |
| EventOccurred | Event | Simulation | Indicates that an event occurred in the simulation. |
| Extension | Property | Simulation | Sets or returns the simulation's extension object. This is used to allow items in the simulation to directly access the properties and methods of the extension object. |
| FindItems | Method | Simulation | Returns a collection of items found using the specified query. |
| Format | Method | Simulation | Returns the result of applying a format string to an expression. |
| ForwardEvent | Method | Simulation | Forwards the specified event to the specified object. |
| GetItem | Method | Simulation | Returns the item with the specified ItemID. |
| Item | Method | Simulation | Returns the item with the specified ItemID. |
| ItemCount | Method | Simulation | Returns the number of items in the simulation. |
| ItemLocationChanged | Event | Simulation | Indicates that an item moved to a new location, passing the item and its previous location. |
| Load | Method | Simulation | Loads the simulation items from a path or url. |
| LoadXML | Method | Simulation | Loads the simulation items from a string containing XML. |
| Object | Property | Simulation | An object that represents the Simulation Item, as created in script. |
| PeekEvent | Method | Simulation | Returns the next scheduled event. |
| PostEvent | Method | Simulation | Sends an event asynchronously to an item (or object). |
| Random | Method | Simulation | Returns a random number from a set of available distributions. |
| RandomSeed | Method | Simulation | Sets or returns the Simulation object's random seed value. |
| RandomizeSeed | Method | Simulation | Randomizes the random number generator's seed value. |
| ReleaseAll | Method | Simulation | Releases all loaded items, and returns the simulation to the condition prior to any calls to load. |
| Reset | Method | Simulation | Initializes the simulation to the state immediately following the most recent load. |
| RetractEvent | Method | Simulation | Prevents a scheduled event from occurring. |
| Run | Method | Simulation | Runs the simulation object. |
| ScheduleEvent | Method | Simulation | Schedules an event. |
| SendEvent | Method | Simulation | Sends an event synchronously to an item (or object) and returns the result. |
| SetItemLocation | Method | Simulation | Sets an item's location. This has the same effect as directly changing an item's location property. |
| Simulation | Property | Simulation | Returns the Simulation object. (This is not the same as the Object property, because the Object property has a dynamic interface.) |
<!-- SRML 2.0 Schema ...................................................... -->
<!-- file: SRML.xdr -->
<!-- SRML 2.0 Schema
This is the Simulation Reference Markup Language (SRML) 2.0, an XML
application for describing discrete event simulations,
both their structure and behavior.
Copyright 2001-2002 Boeing
It is provided "as is" without expressed or implied warranty.
Revision: $Id: Overview.html,v 1.3 2018/10/09 13:20:48 denis Exp $
Revisions: editor and revision history at EOF
-->
<Schema xmlns="urn:schemas-microsoft-com:xml-data"
xmlns:dt="urn:schemas-microsoft-com:datatypes">
<!-- Note: reference elements are templates for elements in other schemas -->
<AttributeType name="Source" dt:type="string" required="no"/>
<ElementType name="Script" content="textOnly" model="closed">
<AttributeType name="Type" dt:type="string" default="text/javascript" required="no"/>
<AttributeType name="Language" dt:type="string" required="no"/>
<attribute type="Type"/>
<attribute type="Language"/>
<attribute type="Source"/>
</ElementType>
<ElementType name="Link" content="mixed" model="open">
<AttributeType name="Name" dt:type="string" required="no"/>
<AttributeType name="Target" dt:type="string" required="yes"/>
<AttributeType name="WithPropertiesChanged" dt:type="string" required="no"/>
<AttributeType name="WithLocationChanged" dt:type="string" required="no"/>
<AttributeType name="WithEventsReceived" dt:type="string" required="no"/>
<attribute type="Name"/>
<attribute type="Target"/>
<attribute type="WithPropertiesChanged"/>
<attribute type="WithLocationChanged"/>
<attribute type="WithEventsReceived"/>
</ElementType>
<ElementType name="Links" content="eltOnly" order="many" model="open">
<element type="Link"/>
</ElementType>
<AttributeType name="Quantity" dt:type="i4" required="no"/>
<AttributeType name="LocationFixed" dt:type="string" required="no"/>
<AttributeType name="Name" dt:type="string" required="no"/>
<AttributeType name="ItemID" dt:type="string" required="no"/>
<AttributeType name="ID" dt:type="string" required="no"/>
<!-- The reference element, Item, is defined here. -->
<ElementType name="Item" content="mixed" order="many" model="open">
<AttributeType name="ItemClass" dt:type="idref" required="no"/>
<attribute type="Name"/>
<attribute type="ItemClass"/>
<attribute type="Quantity" default="1"/>
<attribute type="LocationFixed"/>
<attribute type="Source"/>
<attribute type="ItemID"/>
<attribute type="ID"/>
<element type="Script"/>
<element type="Item"/>
<element type="Link"/>
<element type="Links"/>
</ElementType>
<ElementType name="ItemClass" content="mixed" order="many" model="open">
<AttributeType name="SuperClasses" dt:type="idrefs" required="no"/>
<AttributeType name="Name" dt:type="id" required="yes"/>
<attribute type="SuperClasses"/>
<attribute type="Name"/>
<attribute type="Source"/>
<element type="Script"/>
<element type="Item"/>
</ElementType>
<ElementType name="ItemClasses" content="mixed" order="many" model="open">
<element type="ItemClass"/>
</ElementType>
<!-- The reference element, Parameter, is defined here. -->
<ElementType name="Parameter" content="mixed" order="many" model="open"/>
<ElementType name="ItemEvent" content="mixed" order="many" model="open">
<AttributeType name="EventID" dt:type="string" required="no"/>
<AttributeType name="Name" dt:type="string" required="yes"/>
<AttributeType name="Time" dt:type="date" required="no"/>
<AttributeType name="Format" dt:type="string" default='Method' required="no"/>
<AttributeType name="Cascade" dt:type="string" default='CascadeNone' required="no"/>
<AttributeType name="Source" dt:type="string" required="no"/>
<AttributeType name="Cancel" dt:type="string" required="no"/>
<attribute type="EventID"/>
<attribute type="Name"/>
<attribute type="Time"/>
<attribute type="Format"/>
<attribute type="Cascade"/>
<attribute type="Source"/>
<attribute type="Cancel"/>
<element type="Parameter"/>
</ElementType>
<ElementType name="EventClasses" content="mixed" order="many" model="open">
<element type="EventClass"/>
</ElementType>
<ElementType name="EventClass" content="mixed" order="many" model="open">
<AttributeType name="SuperClasses" dt:type="idrefs" required="no"/>
<AttributeType name="Name" dt:type="id" required="yes"/>
<attribute type="SuperClasses"/>
<attribute type="Name"/>
<attribute type="Source"/>
<element type="Script"/>
</ElementType>
<ElementType name="EventSink" content="mixed" order="many" model="open">
<AttributeType name="Name" dt:type="string" required="yes"/>
<AttributeType name="Enabled" dt:type="string" required="no"/>
<AttributeType name="EventClasses" dt:type="string" required="no"/>
<AttributeType name="ItemClasses" dt:type="string" required="no"/>
<AttributeType name="WithPropertiesChanged" dt:type="string" required="no"/>
<AttributeType name="WithLocationChanged" dt:type="string" required="no"/>
<AttributeType name="WithEventsReceived" dt:type="string" required="no"/>
<AttributeType name="WithItemLifetime" dt:type="string" required="no"/>
<attribute type="Name"/>
<attribute type="EventClasses"/>
<attribute type="ItemClass"/>
<attribute type="WithPropertiesChanged"/>
<attribute type="WithLocationChanged"/>
<attribute type="WithEventsReceived"/>
<attribute type="WithItemLifetime"/>
<element type="Script"/>
</ElementType>
<ElementType name="Simulation" content="mixed" order="many" model="open">
<attribute type="Source"/>
<element type="Script"/>
<element type="ItemClass"/>
<element type="Item"/>
</ElementType>
<ElementType name="Simulations" content="mixed" order="many" model="open">
<element type="Simulation"/>
</ElementType>
</Schema>
<!-- Revision History:
Initial 1.0 draft 2001-04-08
Steven W. Reichenthal
Update 2.0 draft 2002-04-08
Steven W. Reichenthal
-->
<!-- end of SRML 2.0 Schema ................................................ -->
<!-- ....................................................................... -->
<?xml version="1.0" encoding="UTF-16"?>
<!DOCTYPE xsd:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN" "XMLSchema.dtd" [
<!ENTITY % p 'xsd:'>
<!ENTITY % s ':xsd'>
]>
<!-- SRML 2.0 Schema ...................................................... -->
<!-- file: SRML.xdr -->
<!-- SRML 2.0 Schema
This is the Simulation Reference Markup Language (SRML) 2.0, an XML
application for describing discrete event simulations,
both their structure and behavior.
Copyright 2001-2002 Boeing
It is provided "as is" without expressed or implied warranty.
Revision: $Id: Overview.html,v 1.3 2018/10/09 13:20:48 denis Exp $
Revisions: editor and revision history at EOF
-->
<xsd:schema version="1.0" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
<!-- Note: reference elements are templates for elements in other schemas -->
<xsd:attribute name="Source" type="xsd:string"/>
<!-- "Script" element -->
<xsd:element name="Script">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="Type" use="default" value="text/javascript" type="xsd:string"/>
<xsd:attribute name="Language" type="xsd:string"/>
<xsd:attribute ref="Source"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<!-- "Link" element -->
<xsd:element name="Link">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:attribute name="Name" type="xsd:string"/>
<xsd:attribute name="Target" use="required" type="xsd:string"/>
<xsd:attribute name="WithPropertiesChanged" type="xsd:string"/>
<xsd:attribute name="WithLocationChanged" type="xsd:string"/>
<xsd:attribute name="WithEventsReceived" type="xsd:string"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "Links" element -->
<xsd:element name="Links">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="Link"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<xsd:attribute name="Quantity" type="xsd:int"/>
<xsd:attribute name="LocationFixed" type="xsd:string"/>
<xsd:attribute name="Name" type="xsd:string"/>
<xsd:attribute name="ItemID" type="xsd:string"/>
<xsd:attribute name="ID" type="xsd:string"/>
<!-- The reference element, Item, is defined here. -->
<!-- "Item" element -->
<xsd:element name="Item">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Script"/>
<xsd:element ref="Item"/>
<xsd:element ref="Link"/>
<xsd:element ref="Links"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:attribute ref="Name"/>
<xsd:attribute name="ItemClass" type="xsd:IDREF"/>
<xsd:attribute name="Quantity" use="default" value="1" type="xsd:int"/>
<xsd:attribute ref="LocationFixed"/>
<xsd:attribute ref="Source"/>
<xsd:attribute ref="ItemID"/>
<xsd:attribute ref="ID"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "ItemClass" element -->
<xsd:element name="ItemClass">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Script"/>
<xsd:element ref="Item"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:attribute name="SuperClasses" type="xsd:IDREFS"/>
<xsd:attribute name="Name" use="required" type="xsd:ID"/>
<xsd:attribute ref="Source"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "ItemClasses" element -->
<xsd:element name="ItemClasses">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="ItemClass"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- The reference element, Parameter, is defined here. -->
<!-- "Parameter" element -->
<xsd:element name="Parameter">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "ItemEvent" element -->
<xsd:element name="ItemEvent">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Parameter"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:attribute name="EventID" type="xsd:string"/>
<xsd:attribute name="Name" use="required" type="xsd:string"/>
<xsd:attribute name="Time" type="date"/>
<xsd:attribute name="Format" use="default" value="Method" type="xsd:string"/>
<xsd:attribute name="Cascade" use="default" value="CascadeNone" type="xsd:string"/>
<xsd:attribute name="Source" type="xsd:string"/>
<xsd:attribute name="Cancel" type="xsd:string"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "EventClasses" element -->
<xsd:element name="EventClasses">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="EventClass"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "EventClass" element -->
<xsd:element name="EventClass">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Script"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:attribute name="SuperClasses" type="xsd:IDREFS"/>
<xsd:attribute name="Name" use="required" type="xsd:ID"/>
<xsd:attribute ref="Source"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "EventSink" element -->
<xsd:element name="EventSink">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Script"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:attribute name="Name" use="required" type="xsd:string"/>
<xsd:attribute name="EventClasses" type="xsd:string"/>
<xsd:attribute name="ItemClasses" type="xsd:string"/>
<xsd:attribute name="WithPropertiesChanged" type="xsd:string"/>
<xsd:attribute name="WithLocationChanged" type="xsd:string"/>
<xsd:attribute name="WithEventsReceived" type="xsd:string"/>
<xsd:attribute name="WithItemLifetime" type="xsd:string"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "Simulation" element -->
<xsd:element name="Simulation">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Script"/>
<xsd:element ref="ItemClass"/>
<xsd:element ref="Item"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:attribute ref="Source"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- "Simulations" element -->
<xsd:element name="Simulations">
<xsd:complexType mixed="true">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="Simulation"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="lax"/>
<xsd:any namespace="##targetNamespace"/>
</xsd:choice>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- XDR datatype derivations -->
</xsd:schema>
<!-- Revision History:
Initial 1.0 draft 2001-04-08
Steven W. Reichenthal
Update 2.0 draft 2002-04-08
Steven W. Reichenthal
-->
<!-- end of SRML 2.0 Schema ................................................ -->
<!-- ....................................................................... -->
[1] XML is a standard under the World Wide Web Consortium (http://www.w3.org)
[2] MathML is a standard under the World Wide Web Consortium (http://www.w3.org)
[3] XML Schemas express shared vocabularies and allow machines to carry out rules made by people (http://www.w3.org/XML/Schema)
[4] The DOM is a language- neutral interface that allows programs and scripts to dynamically access the content, structure and style of documents (http://www.w3.org/DOM)
[5] XSLT is a language for transforming XML documents (http://www.w3.org/Style/XSL)
[6] Dynamic HTML is an extension of HTML provides more interactivity than standard HTML ( http://msdn.Microsoft.com/workshop/author/dhtml.dhtmlovw.asp)
[7] XHTML is the reformulation of HTML as an XML application (http://www.w3.org/TR/xhtml11)
[8] XML Schema: Datatypes is part 2 of the specification of the XML Schema language. It defines facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. ( http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/datatypes.html)
[9] XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references. (http://www.w3.org/TR/REC-xml-names/)
[10] XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. (http://www.w3.org/TR/xpath)
[11] ID and IDREFS are XML data types that are used for providing and validating non-hierarchical links in XML documents ( http://www.w3.org/TR/2000/REC-xml-20001006#sec-attribute-types)
[12] Kay, Alan, "Microelectronics and the Personal Computer", Scientific American, September 1977, pp. 230-244.