<?xml version="1.0" encoding="US-ASCII"?>
<!-- Revision 1 of xADL/1.0 by Rohit Khare, June 1, 1999 -->

<!-- xADL
====================================================================
       This is an arbitrary parent/container element that demarcates the
       beginning of a "xADL block" of information.

       In the future, we want xADL webs of documents spun from
       individual XML instances describing single instances,
       interfaces, or architectural configurations. However,
       initial implementations will use a single file, so we
       created a "surrogate parent" element which functions as
       the root for XML purposes -->

<!ELEMENT xADL   ( ComponentType | ConnectorType | Architecture )* >

<!-- ARCHITECTURE
============================================================
       The Architecture tag represents a single configuration
       of instances by the directed edges between them. Thus,
       the content model is a list of Link tags. -->

<!ELEMENT Architecture     (Topology , (Component | Connector)*) >
<!ATTLIST Architecture      name            CDATA   #REQUIRED >

<!ELEMENT Topology         (Link*) >
<!ATTLIST Topology          name            CDATA   #REQUIRED >

<!-- LINK
====================================================================
       The Link Element represents a single directed edge between any two
       instances (Components or Connectors). In particular, the edge endpoint
       can be specified as a particular Port by using XLink Fragment
       identifiers, e.g. gameboard#Top, or vault#DepositorySlot.

       NOTE: NAMED LINKS
       In general, the xADL DTD emphasizes accessing any element by a unique
       name. Links are uniquely identified by the from and to hooks;
       that is, the same link may not be repeated. Since instance names, nor
       port names, can contain the colon character, each Link shall have
       an implied "name" parameter constructed as the string "from:to"

       NOTE: SEMANTICS
       The DTD alone cannot (syntactically) guarantee that from and to values
       are names from the space of Components or Connectors only.

       NOTE: XLINK SYNTAX
       In the future, XLink 'roles' and out-of-line links may have semantics
       particular to ADLs built on top of xADL.

       NOTE: C2-SPECIFIC SEMANTICS: DIRECTION
       In C2, links are _not_ directional; messages may flow in either
       direction. Also, there is a convention that 'from' is "above" 'to'
       That is, all links should be specified "down" the architecture.

       NOTE: C2-SPECIFIC SEMANTICS: KIND
       Though there is a rule that Components can only be linked to Connectors
       (and an exception for Connector-Connector links), the DTD cannot
       (syntactically) guarantee the type of each link endpoint.  -->

<!ELEMENT Link  EMPTY>
<!ATTLIST Link  FromInstance      CDATA   #REQUIRED
                FromPort          CDATA   #REQUIRED
                ToInstance        CDATA   #REQUIRED
                ToPort            CDATA   #REQUIRED
                name              CDATA   #IMPLIED >


<!-- COMPONENT TYPE
==========================================================
       This tag has only one xADL attribute, name. At the basic xADL level,
       the only salient feature of a ComponentType is its Methods. A type
       hierarchy, if any, can be constructed with the Supports child element

       C2, in particular DRADEL, adds analysis of  "behavior",
       for which see the optional child tag Behavior -->

<!ELEMENT ComponentType (Supports*, Method*, C2:Behavior?) >
<!ATTLIST ComponentType  name          CDATA                 #REQUIRED
                         C2:language   CDATA                 #IMPLIED
                         C2:implModule CDATA                 #IMPLIED
                         C2:OS         CDATA                 #IMPLIED >


<!-- CONNECTOR TYPE
==========================================================
       This tag has only one xADL attribute, name. At the basic xADL level,
       there are no further refinements on a Connector except its type
       relations (if any).

       C2 adds the attribute filter, specifying one of several predefined
       choices. The default setting is no_filtering

       NOTE: xADL SCOPE
       It may be that a generic ADL kit _should_ provide a hook to specify
       Methods on the Connector itself. It would be forward-compatible to
       add a Methods* production to the content model of ConnectorType if
       so desired. -->

<!ELEMENT ConnectorType (Supports*) >
<!ATTLIST ConnectorType  name          CDATA                  #REQUIRED
                         C2:filter   ( no_filtering               |
                                       notification_filtering     |
                                       message_filtering          |
                                       prioritized                |
                                       message_sink )         'no_filtering'
                         C2:language   CDATA                  #IMPLIED
                         C2:implModule CDATA                  #IMPLIED
                         C2:OS         CDATA                  #IMPLIED >


<!-- METHOD
=================================================================
       The Method tag describes a single operation upon several
       Parameters (which can represent inputs, outputs, or both).

       C2 adds the direction attribute.
       C2, in particular DRADEL, referred to these as InterfaceElements.
       C2, in particular DRADEL, maps each Method to an Operation for
       behavioral analysis. C2:mapToOper cites a value for uid which occurs
       on an Operation (since it is not clear if Operation names are unique
       enough) -->

<!ELEMENT Method    (Parameter*) >
<!ATTLIST Method     name            CDATA                 #REQUIRED
                     C2:direction  ( provide | require )   #REQUIRED
                     C2:mapToOper    IDREF                 #IMPLIED >

<!-- PARAMETER
===============================================================
       To support arbitrary method signatures in xADL, parameter roles
       (in, out, inout; default of 'in') are specified separately for
       each parameter. This allows multiple results, for examples.
       The Parameter tag is an empty element.
       Its type attribute is an opaque string for our purposes (e.g. "Int")

       C2, in particular DRADEL, maps each Parameter to a Variable for
       behavioral analysis. C2:mapToVar cites a value for uid which occurs
       on an Variable (since it is not clear if Variable names are unique
       enough) -->

<!ELEMENT Parameter     EMPTY>
<!ATTLIST Parameter     name         CDATA                 #REQUIRED
                        type         CDATA                 #REQUIRED
                        role       ( in | out | inout )    'in'
                        C2:mapToVar  IDREF                 #IMPLIED >

<!-- COMPONENT
===============================================================
       The Component tag is a named instance that can point to one (or more)
       ComponentTypes it supports. It can expose these functions over one
       (or more) named Ports.

       NOTE: C2 LINK SETS
       C2 data structures traditionally put all of a brick's
       connections to other bricks on this one, but we have chosen to
       entirely externalize this responsibility to the Link tags, leaving
       it as a simple computation over the hyperweb to compute sets such
       as "aboveCompLinks". -->

<!ELEMENT Component (Port*, Supports*) >
<!ATTLIST Component  name                CDATA             #REQUIRED
                     ArchShell:running ( true | false )    'true'
                     supports            CDATA             #REQUIRED >


<!-- CONNECTOR
===============================================================
       The Connector tag is a named instance that can point to one (or more)
       ConnectorTypes it supports. It can expose these functions over one
       (or more) named Ports. -->

<!ELEMENT Connector (Port*, Supports*) >
<!ATTLIST Connector  name                CDATA             #REQUIRED
                     ArchShell:running ( true | false )    'true'
                     supports            CDATA             #REQUIRED >

<!-- PORT
====================================================================
       The Port tag is a qualifier for naming Link endpoints within a given
       Component or Connector.

       NOTE: C2 USAGE
       C2-style architectures will have to explicitly add <Port type="Top">
       and <Port type="Bottom"> to every single Component and Connector, and
       also specify #Top and #Bottom on every link. -->

<!ELEMENT Port EMPTY>
<!ATTLIST Port type      CDATA       #REQUIRED >


<!-- SUPPORTS
================================================================
       The Supports tag specifies type-compatibility for Component and
       Connector. However, the downside is that XML verification
       alone can not enforce type-coherency (i.e. that a Component's Supports
       child can only link to ComponentTypes rather than ConnectorTypes).

       The "type" attribute must be a unique string ocurring in some other
       ComponentType or ConnectorType's "name" attribute. -->

<!ELEMENT Supports EMPTY>
<!ATTLIST Supports type  CDATA       #REQUIRED >

<!-- C2:BEHAVIOR
=============================================================
       The following C2:prefixes tags all support C2, in particular DRADEL,
       in specifying component behavior. It also adds mapToOper and mapToVar
       attributes to Method and Parameter, respectively, to link behavioral
       specifications to interfaces.

       The C2:Behavior tag has only one xADL attribute, name,
          which is implied as the name of the encolsing ComponentType.

       Its children map onto C2SADL's specifications for state variables,
       invariants, and operations. -->

<!ELEMENT C2:Behavior  (C2:State,
                        C2:Invariant,
                        C2:Operation*) >
<!ATTLIST C2:Behavior   name  CDATA    #IMPLIED >


<!-- C2:STATE
================================================================
       State is an anonymous grouping tag to bracket
       related items from the original C2SADL spec -->

<!ELEMENT C2:State (C2:Variable | C2:Function)* >


<!-- C2:VARIABLE
=============================================================
       Use C2:Variable rather than xADL:Parameter in Behavior and Let
       since Parameters of an Method are in|out|inout, this is a fresh
       new tag introduced here.

       The uid attribute is a unique string for C2:mapToVar to hyperlink
       to -->

<!ELEMENT C2:Variable  EMPTY>
<!ATTLIST C2:Variable  name        CDATA               #REQUIRED
                       type        CDATA               #REQUIRED
                       uid         CDATA               #REQUIRED >


<!-- C2:FUNCTION
=============================================================
       From and To values are supposed to be types, either language
       built-ins (Integer, etc) or custom types -->

<!ELEMENT C2:Function   EMPTY>
<!ATTLIST C2:Function   name       CDATA               #REQUIRED
                        from       CDATA               #REQUIRED
                        to         CDATA               #REQUIRED >


<!-- C2:INVARIANT
============================================================
       Invariant is an anonymous grouping tag to bracket
       related Expressions from the original C2SADL spec. -->

<!ELEMENT C2:Invariant   (C2:Expression)* >


<!-- C2:EXPRESSION
===========================================================
       Expression is an anonymous grouping tag to bracket unparsed expression
       text from the original C2SADL spec.
       E.g. <C2:Expression> x \eqgreater y </C2:Expression> -->

<!ELEMENT C2:Expression   ANY >


<!-- C2:OPERATION
============================================================
       Operation is a named, uniquely identified grouping tag to bracket
       related information from the original C2SADL spec. In particular,
       it may include at most one Let, Pre, and Post sections. -->

<!ELEMENT C2:Operation   (C2:Let?, C2:Pre?, C2:Post?)>
<!ATTLIST C2:Operation    name         CDATA                #REQUIRED
                          direction  ( provide | require )  #REQUIRED
                          uid          CDATA                #REQUIRED >

<!ELEMENT C2:Let          (C2:Variable)* >
<!ELEMENT C2:Pre          (C2:Expression) >
<!ELEMENT C2:Post         (C2:Expression) >