Copyright © 2013 the Contributors to the Algorithmic Modelling 1.0 Specification, published by the Algorithmic Modelling Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.
A "model" refers to an abstract description of the composition and relative dynamic behaviour of the sub-parts of some system
This specification describes an XML representation of such a model, to be used as reference for more specific model types
The presence of each of non-model elements appearing, verbatim, in a model document causes the creation, at run-time, of a corresponding "artefact", situated within the implementation's run-time environment, each of which are then transformed, in some way, due to the presence of one of more (possibly nested) model elements
While these run-time artefacts are, generally, some type of XML Information Item, data in other formats may also be referenced through the use of a special attribute named "opaque", whose value contains an IRI which will, when resolved, yield the opaque data
The other name-spaces used in this specification are given in the following table
Prefix | Namespace | Notes |
---|---|---|
xs | http://www.w3.org/2001/XMLSchema | XML Schemas |
sc | http://www.w3.org/2005/07/scxml | State Chart |
xml | http://www.w3.org/XML/1998/namespace | used to specify element IDs (via "xml:id" [XML11 ]) |
There are several attributes common to all model elements
Related elements may possess a "constraint" attribute constraining the element's relationships to other elements, as expressed by an XPath expression evaluating to a non-zero value when the constraint holds
Those elements best classified as part of a finite state machine may contain attributes from the State Chart [STATECHART ] name-space having a local name reflecting equivalence between the roles a Chart element of that local name plays in the State Chart semantics, and the role the element containing that attribute plays in the state machine in which that element participates
The value of such an attribute consists of a comma-separated list of name-value pairs, in each name and value represents those of that State Chart attribute.
The receipt or sending of a message to or from, respectively, an element may be specified to trigger the execution of some process by the appearance, on the element, of the "receives" and "sends" attributes, whose value is the ID of a process when, when executed, is, to be passed a single parameter containing a reference to the sent or received message
Any element may also contain a "type" attribute whose value contains a reference to the element of the XML Schema [SCHEMAS ] type of that element
The example below illustrates a use of these common attributes: the "len" attribute of the "parent" element (which itself acts as a state within a state machine), has a type identified in the XML Schema element, located elsewhere in the document having the ID "type", constrained to be equal to the number of "child" elements (the first of which acts as a transition to the second within that state machine). The parent element executes the processes having IDs "http://www.example.com#c" and http://www.example.com#d", respectively, on receipt of and when sending a message
<parent sc:state=type="#type" sends="http://www.example.com#c"
receives="http://www.example.com#d">
"xml:id=parent"
constraint="number(@len)=count(child)">
<child xml:id="child">
<child sc:transition="target=#child">
</parent>
The model itself consists of any nested combination of the following, beneath a top-level "model" element (each of the items below will be further discussed when introduced below)
This model is designed to act as a reference over which more specific types of models may be layered (possibly with some type-specific modifications)
The type system established by XML Schemas [SCHEMAS ] is augmented in two ways: by the specification of namespaces and the addition of methods (that is, behaviourattached to an artefact).
A namespace root is created by the appearance of a "namespace" element, and names are added to such namespaces by the appearance of a "name" attribute on an element, the value of which specifies the name itself, and the value of the "within" attribute of which specifies either the name-space (for "top-level" names) or name (other than "top-level" names) within which the name exists
Methods are created by appearance of a "to" attribute on an element, the value of which specifies the ID of the element to which the method is attached, and a "content" attribute, the value of which specifies the ID of the "process" element constituting the content of the method (both these attributes must be present on the element for the method to attach)
The following example specifies a namespace, within which the names "abc" and "xyz" exist, and the attachment of a method consisting of a process having ID "z" to an element with ID "c"
<namespace xml:id="a" />
<b name="abc" within="#a" />
<c name="xyz" within="#a" />
<d to="#c" content="#z" />
This is specified through the use of one or more attributes of two possible types
The first, the "provides" attributes, specifies, in the attribute's value, the XML Schemas element of the type representing an interface the run-time object that element represents provides
The value of the second, the "requires" attribute, contains the ID of the XML Schemas type of a component that an implementation must determine to be present in the component run-time system, so the run-time object may make calls to other run-time objects providing that interface
The following example illustrates the use of component compositing, declaring an element providing two components having the XML Schemas IRIs of "http://www.example.com#x" and "http://www.example.com#y", and another requiring an XML Schemas IRI of "http://www.example.com#a"
<a provides="http://www.example.com#x"
provides="http://www.example.com#y" />
<b provides="http://www.example.com#y"
requires="http://www.example.com#a" />
The (possibly nested) "partition" element isolates run-time artefacts generated by declarations in the sub-tree of the element from artefacts outside the sub-tree
The following example demonstrates three partitioned elements having tags "a", "b" and "c" isolated from a second partition containing both an element with tag "d" and a sub-partiton containing elements with tags "e" and "f", respectively
<partition>
<a />
<b />
<c />
</partition>
<partition>
<d />
<partition>
<e />
<f />
</partition>
</partition>
The term "imperative Processing", as specified in the "process" element, refers to a set of "imperative statements" transforming, at run-time, a stream of artefacts arriving on the designated the "input stream" of that process (as specified by the element the ID of which forms the value of the "in" attribute), then output to the element referenced in the value of the "out" attribute
The actual content of the process consists of the result of either resolving the reference to an XProc step [XPROC] forming the value of the element's "step" attribute, or of resolving a reference to the State Chart [STATECHART ] Executable Content forming the value of the element's "script" attribute
The following example demonstrates a process the content of which is formed from an XProc step located at "http://www.example.com#step" taking, as input, the output of a process the content of which is formed from the State Chart executable content located at "http://www.example.com#sc"
<process xml:id="proc1"
step="http://www.example.com#step" />
<process in=#proc1"
script="http://www.example.com#sc" />
A "stereotype" creates a "template" instantiated, at run-time, by a group of objects, each fulfilling named "roles" within that stereotype
The template for the stereotype itself is established by the appearance of a "stereotype" element containing one or more "role" sub-elements, each containing a "name" attribute, the value of which names the role, and a "matches" attribute, the value of which contains an XPath expression constraining the location and/or nature of the role within the stereotype
This XPath expression, the context node of which is set to the element in on which the "stereotype" attribute is located, is augmented with a "model:role" function returning the node bound to the role, within the stereotype having the name passed in the function's first argument
The following example illustrates a "family" stereotype, whose "mother" role is constrained to be a female whose children include the "son" or "daughter" role in the stereotype, whose "father" role to a male constrained in the same manner, whose "son" role is constrained to be a male whose father or mother has the "father" or "mother" role in the stereotype and whose "daughter" role as a female constrained in the same manner, instantiated by two elements denoting a mother and father, and two denoting a son and daughter
<stereotype xml:id="family">
<role name="father" matches="person[@gender='male']
and (person/@mother is model:role('mother')
or person/@father is model:role("father'))" />
<role name="mother" matches="person[@gender='female']
and (person/@mother is model:role('mother') or
person@/@father is model:role("'father'))" />
<role name="son" matches="person[@gender='male']
and (person/child[model:role('son')] or
person/child[model:role('daughter')])" />
<role name="daughter" matches="person[@gender='female']
and (person/child[model:role('son')] or
person/child[model:role('daughter')])" />
</stereotype>
<group stereotype="#family">
<person xml:id="john" gender="male"
role="father" >
<child>
<person xml:id="emily"
gender="female"
erole="daughter"
father="#john"
mother="#jenny" />
</child>
<child>
<person xml:id="tom"
gender="male"
role="son"
father="#john"
mother="#jenny" /"&;gt
</child>
</person>
<person xml:id="jenny" gender="female"
role="mother" />
<child>
<person xml:id="emily"
gender="female
role="daughter"
father="#john"
mother="#jenny" />
</child>
<child>
<person xml:id="tom"
gender="male"
role="son"
father="#john"
mother="#jenny" />
</child>
</person>
</group>
This aspect of the model refers to the capability of a process to wait to start until signalled by the process identified by the content of the element's "wait_on" attribute, and to notify when completed the process identified by the content of the element's "notify" attribute.
The following example illustrates two elements, the first of which waits got the second to complete which, itself, notifies the first on completion
<a wait_on="#a" xml:id="b" />
<b notify="#b" xml:id="a" />
The timing of messages between objects and the relative order of these messages is specified through use of the "messaging" element
Within this element are located a "path" element, the children of which identify the path of the messages, followed by a set of "message" elements, each identifying a message along that path
The children of the "path" element collectively identify the path of run-time objects, within the model, for which messaging is specified, while each "message" sub-element represents a single message along that path, to be referenced by certain timing- and sequencing-related attributes of the remaining elements
The "starts" attribute of such an element references the message creating, when received, the run-time object corresponding to the element on which the attribute appears, while the value of the "ends" attribute destroys the analogous object
The value of the "delay" attribute specifies the delay, in seconds, between the sending of the message and the creation or destruction of the object
The value of the "after" attribute references the message that must may only be sent after the run-time object has received the message referenced in the value of the "ctx" attribute, while the value of the "before" attribute references the message that may only be sent before the analogous message has been received
Similarly, the value of the "delay" attribute specifies the delay, in seconds, between the the receipt of the message and the message before or after it must be received
The following example demonstrates a path of three elements the first of which must creates start the second, the first of which may only be sent after the second, with a delay of 4 seconds
<messaging>
<path>
<a xml:id="a" />
<b xml:id="b" />
<c xml:id="c" />
</path>
<message xml:id="x" />
<message xml:id="y" />
<a starts="#y" />
<b after="#x" ctx="#y" delay="4" />
</messaging>