W3C

SRML - Simulation Reference Markup Language

W3C Note 18 December 2002

This version:
http://www.w3.org/TR/2002/NOTE-SRML-20021218
Latest version:
http://www.w3.org/TR/SRML
Author:
Steven W. Reichenthal, Boeing

Abstract

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.

Status of this document

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.

Table of Contents

  1. Background
    1. General simulation process
    2. Simulation needs and challenges
    3. Suitability of XML technologies to represent and execute simulations
    4. Relationship of SRML to XML
    5. Language goals
  2. SRML Elements
    1. The Simulations element
    2. The Simulation element
    3. The Script element
    4. The ItemClasses element
    5. The ItemClass element
    6. The Item element
    7. The Link element
    8. The Links element
    9. The EventClasses element
    10. The EventClass element
    11. The EventSink element
    12. The Events element
    13. The ItemEvent element
    14. The Parameter element
    15. The SRML processing instruction
  3. SRML Tutorial
    1. SRML language concepts
    2. Items, properties, elements and attributes
    3. Item behavior
    4. Locations
    5. Item quantities
    6. Links
    7. Additional item characteristics
    8. Changing an item's location
    9. Items with fixed locations
    10. Finding items
    11. Events
    12. Main script
    13. Item classes
    14. Super-classes
    15. Integration and distribution
  4. Runtime Environment
    1. External environment
    2. Simulation object
    3. Loading a simulation
    4. Running a simulation
  5. SRML Quick Reference
    1. XML names
    2. Intrinsic item members
    3. Simulation runtime members
  6. XDR Schema for SRML
  7. XML Schema for SRML
  8. References
  9. Acronyms

1. Background

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.

1.1 General simulation process

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.

1.2 Simulation needs and challenges

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:

1.3 Suitability of XML technologies to represent and execute simulations

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.

1.4 Relationship of SRML to XML

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 -

1.5 Language goals

The Simulation Reference Markup Language is designed according to the following goals:

  1. Specify a flexible reference standard for representing simulations.
  2. Provide enough expressive power to model most anything for purposes of simulation.
  3. Choose constructs that are simple, yet expressive, such that models can be developed and maintained using a text editor at minimum.
  4. Specify only a small set of predefined element names; maximize use of elements in user-defined schemas.
  5. Support models defined in both single and multiple source files.
  6. Maximize use of widely accepted standards: XML, JavaScript, and allow other languages to be "plugged in".
  7. Define semantics that are neutral and flexible, so as not to stifle simulation software vendors.
  8. Provide a language similar to XHTML, with individual element behavior and dynamic DOM functionality, yet targeted for simulations.
  9. Provide object-oriented capabilities for modeling generalization and containment relationships, as well as multiplicity.
  10. Maintain presentation independence.

2. SRML Elements

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.

2.1 The Simulations element

<!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>

2.2 The Simulation element

<!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.

Source
The Source attribute specifies the location of a document or object class that provides an external source of structure and/or behavior for the item. The value of this attribute is a url. This attribute allows the item to include the definition of an object instance from an externally developed simulation, such as one developed in a Java Bean or other component.

Example:

<Simulation>
     <Script Type='text/javascript'>
     ...
     </Script>
     <ItemClass Name='Vehicle'>
     ...
     </ItemClass>
     <Vehicle Quantity='100'/>
</Simulation>

2.3 The Script element

<!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.

Type
The Type attribute specifies the scripting language of a particular script in the document. The default Type for an SRML script is 'text/javascript'. Scripts can selectively override this default by specifying Type attribute values as necessary.
Language
The Language attribute specifies the scripting language of a particular script in the document and may be used instead of Type.
Source
The Source attribute specifies the location of a document that provides the script code for the item.

Example:

<Script Type='text/javascript'>
...
</Script>

2.4 The ItemClasses element

<!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>

2.5 The ItemClass element

<!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.

Name
The Name attribute specifies the name for the ItemClass. This attribute is required and must be unique within the document.
SuperClasses
The SuperClasses attribute specifies an ordered sequence of ItemClass names that provide default behavior for the ItemClass. An item class specified to the left of another item class has higher priority.
Source
The Source attribute specifies the location of a document or object class that provides an external source of structure and/or behavior for the item. The value of this attribute is a url. This attribute allows the item to include the definition of an object instance from an externally developed item class, such as one developed in a Java Bean or other component.

Example:

<ItemClass Name='Vehicle' SuperClasses='Transportation'>
    <Vehicle HP='400'>
    ...
    </Vehicle>
</ItemClass>

2.6 The Item element

<!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.

ItemClass
The ItemClass attribute specifies the name of the ItemClass that describes this item. This attribute is only needed when using the Item element explicitly.
Quantity
The quantity attribute specifies the number of items constructed at the enclosing location. When loading the document, an SR Simulator will duplicate the element that includes this attribute enough times to obtain the specified quantity of items.
Name
The Name attribute specifies the name of the item. Name is not required for an item, except when LocationFixed is set to True, in which case Name becomes the property name that accesses the item within its enclosing Location item.
LocationFixed
The LocationFixed attribute specifies that an item should have its location fixed. This makes the item directly accessible to the location through its Name. For example if "itemname" is location fixed, then it can be accessed through location.itemname. If two items have the same name, the last item will take precedence.
Source
The Source attribute specifies the location of a document or object class that provides an external source of structure and/or behavior for the item. The value of this attribute is a url. This attribute allows the item to include the definition of an object instance from an externally developed class, such as a Java Bean.
ItemID
The ItemID attribute specifies a unique item identifier for the element corresponding to the item. This attribute need not be specified explicitly since a Simulator will automatically generate a unique ItemID for the item. The value of this attribute must not begin with an alphabetical character. When ItemID is specified for one item element in a document, it must also be specified for all the other item elements in the document.

Example:

<Vehicle Quantity='100' Name='Explorer'>
    <Script Type='text/javascript'>
        ...
    </Script>
</Vehicle>

2.7 The Link element

<!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>
Name
The Name attribute specifies the name of the link. This attribute is required except when the Link element is placed within a Links element.
Target
The Target attribute specifies the target item of the link. The value of this attribute is an XPath query string to a location in the document.
Enabled
The Enabled attribute enables and disables event sinking on the link. Event sinking allows messages to be transmitted from the target item to the link's owner.
WithPropertiesChanged
The WithPropertiesChanged attribute specifies a list of property names belonging to the specified item class, which will activate the sink which when changed. This is useful when an item wants to receive notification whenever a property changes in any item belonging to an item class or one of its subclasses.

On activation, the link's owner will receive the event in a script method with the following signature: Name_PropertyChanged(objItem, varNewValue)

WithLocationChanged
The WithLocationChanged attribute specifies that a sink will activate when an item belonging to the specified item class has its location changed. This is useful when an item wants to receive notification whenever the target item's location changes.

On activation, the link's owner will receive the event in a script method with the following signature: Name_LocationChanged(objItem)

EventClasses
The EventClasses attribute specifies a list of event names sent by the target that will activate a sink.

On activation, the link's owner will receive the event in a script method with the following signature: Name_EventName(objTarget, parameter1, ...)

WithItemLifetime
The WithItemLifetime attribute specifies that a sink will activate when the target item is destroyed. This is useful when an item wants to receive notification whenever an item is created for any item belonging to an item class or one of its subclasses.

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

2.8 The Links 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.

Name
The Name attribute specifies the name of the collection of links corresponding to the Links element.

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>

2.9 The EventClasses element

<!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>

2.10 The EventClass element

<!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.

Name
The Name attribute specifies the name for the EventClass. This attribute is required and must be unique within the document.
SuperClasses
The SuperClasses attribute specifies an ordered sequence of EventClass names that provide higher-level generalization of the EventClass. An event class specified to the left of another event class has higher priority when events are processed.

Example:

<EventClass Name='VehicleEvent'/>
<EventClass Name='VehicleStarted' SuperClasses='VehicleEvent'/>
<EventClass Name='CarStarted' SuperClasses='VehicleStarted'/>
<EventClass Name='TruckStarted' SuperClasses='VehicleStarted'/>
<EventClass Name='VehicleCrashed' SuperClasses='VehicleEvent'/>

2.11 The EventSink element

<!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.

Name
The Name attribute specifies the name for the EventSink. This attribute is required and must be unique within enclosing item.
EventClasses
The EventClasses attribute specifies an ordered sequence of EventClass names that the event sink receives.

On activation, the link's owner will receive the event in a script method with the following signature: Name_EventClassName(objTarget, parameter1, ...)

Enabled
The Enabled attribute enables and disables the event sink.
ItemClasses
The ItemClasses attribute specifies a list of item classes to be monitored by the event sink.
WithPropertiesChanged
The WithPropertiesChanged attribute specifies a list of property names belonging to the specified item class, which will activate the sink when changed. This is useful when an item wants to receive notification whenever a property changes in any item belonging to an item class or one of its subclasses.

On activation, the link's owner will receive the event in a script method with the following signature: Name_PropertyChanged(objItem, varNewValue)

WithLocationChanged
The WithLocationChanged attribute specifies that a sink will activate when an item belonging to one of the specified item classes has changed location. This is useful when an item wants to receive notification whenever the location changes for any item belonging to an item class or one of its subclasses.

On activation, the link's owner will receive the event in a script method with the following signature: Name_LocationChanged(objItem)

WithItemLifetime
The WithItemLifetime attribute specifies that a sink will activate when an item belonging to the specified item class is either created or destroyed. This is useful when an item wants to receive notification whenever an item is created for any item belonging to an item class or one of its subclasses.

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:

Sender:
PostEvent(Simulation, "CarStarted", this)
PostEvent(objCar, "CarStarted", this)
objCar.Location = Fwy55
objCar.Speed = 65
Receiver:
<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)

2.12 The Events element

<!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.

2.13 The ItemEvent element

<!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.

EventID
The EventID attribute specifies a unique event identifier for the element corresponding to the event. This attribute need not be specified explicitly since a Simulator will automatically generate a unique EventID for the event. The value of this attribute must not begin with an alphabetical character. When EventID is specified for one item element in a document, it must also be specified for all the other item elements in the document.
Name
The Name attribute specifies the name for the ItemEvent. The value of this attribute does not need to belong to a defined EventClass.
Time
The Time attribute specifies the point in time when the event should occur. If a time is not specified, the event will be posted as a next event for the item.
Format
The Format attribute specifies the format of the event. The values of this attribute include: Method, and ItemEvent.
Cascade
The Cascade attribute specifies the cascade operation of the event. The values of this attribute include: CascadeNone, CascadeUp, CascadeDown.
Source
The optional Source attribute refers to the ItemID of the item sending the event.
Cancel
The optional Cancel attribute specifies whether or not the Cascade operation of the event has been canceled.

2.14 The Parameter element

<!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.

2.15 The SRML processing instruction

Example:

<?SRML TargetEngine='SR_Simulator.Simulation' TargetVersion='1.0' ?>

The SRML processing instruction specifies parameters that govern the processing behavior of an SR Simulator.

3. SRML Tutorial

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.

3.1 SRML language concepts

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>

3.2 Items, properties, elements and attributes

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.

SRML Item Conceptual Model

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'/>

3.3 Item behavior

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();

3.4 Locations

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>

3.5 Item quantities

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>

3.6 Links

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.

3.7 Additional item characteristics

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.

3.8 Changing an item's location

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

3.9 Items with fixed locations

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);

3.10 Finding items

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);

3.11 Events

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.

3.12 Main script

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>

3.13 Item classes

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>

3.14 Super-classes

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>

3.15 Integration and distribution

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.

4. Runtime Environment

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.

4.1 External environment

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.

SRML External Environment

4.2 Simulation object

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.

SRML Runtime Environment

4.3 Loading a simulation

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:

SRML Simulator Object Model

An SR Simulator loads SRML based on the following rules:

  1. A schema is not required.
  2. The DOM (Document Object Model), if used, is loaded first in its entirety, and then the items are loaded.
  3. Elements that begin with the case insensitive prefix: "xml" will not be loaded as items.
  4. Attributes that begin with the case insensitive prefix: "xml" will not be loaded as properties.
  5. Item and property names come from the "baseName" of the DOM node and do not include a namespace prefix. If more than one attribute of an element has the same baseName, the last one takes precedence.
  6. The simulator automatically adds the ItemID attribute to every loaded item. The presence of ItemID attributes prior to loading indicates to the simulator that the document was previously saved by the simulator, or with software that maintains this attribute. If this attribute is specified on the first element it must be specified on them all, otherwise an error will occur. An error will also occur if this attribute is not specified on the first element, but is encountered on another element prior to loading.
  7. Without respect to case, it is illegal for a loadable element to have an attribute named: "location", "items", "node", "simulation", "self", or any other reserved word.

4.4 Running a simulation

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>

5. SRML Quick Reference

5.1 XML names

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.

5.2 Intrinsic item members

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.

5.3 Simulation runtime members

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.)

6. XDR Schema for SRML

<!-- 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.1 2002/12/18 13:46:53 henri 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 ................................................ -->
<!-- ....................................................................... -->

7. XML Schema for SRML

<?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.1 2002/12/18 13:46:53 henri 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 ................................................ -->
<!-- ....................................................................... -->

8. References

[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.

9. Acronyms

SRML
Simulation Reference Markup Language
XML
eXtensible Markup Language
HTML
HyperText Markup Language
MathML
Mathematics Markup Language
W3C
World Wide Web Consortium
DOM
Document Object Model
IDREF
ID Reference
XPath
XML Path Language
XHTML
eXtensible HyperText Markup Language
DHTML
Dynamic HyperText Markup Language
CORBA
Common Object Request Broker Architecture
COM
Component Object Model
HLA
High-Level Architecture