<!--
Basic structure: Messages are sent as MRML texts. In order to make it easy for the
server to know who connects, each message is assigned the id of its session as an attribute.
-->
<!ELEMENT mrml (begin-transaction?,
  (get-configuration
  |configuration-description
  |get-sessions
  |session-list
  |open-session
  |rename-session
  |close-session
  |delete-session
  |get-collections
  |collection-list
  |get-algorithms
  |algorithm-list
  |get-property-sheet
  |property-sheet
  |configure-session
  |query-step
  |query-result
  |user-data
  |error)?,
  end-transaction?)>
<!ATTLIST mrml
   session-id ID #IMPLIED
   transaction-id ID #IMPLIED>

<!--
Request: get-configuration
This is the message an MRML client sends to the server on connection. The message
get-configuration gives information about the basic server configuration.
-->
<!ELEMENT get-configuration EMPTY>

<!--
Response: configuration-description
The get-configuration message is anwered by a message which is supposed to hold
a description about anything which is nonstandard MRML.
-->
<!ELEMENT configuration-description EMPTY>

<!--
Request: get-sessions
The get-sessions message permits the user to request exsisting sessions for a given
user. It is sent by the client directly after after the configuration-description has been
delivered, and prior to any other activity.
Authentification happens before any other activity to give the server the possibility to
customise any other information sent to the user. For example, it might be sensible to
send different property sheets to different classes of users, or to render some parts of the
database only visible to the own work group.
-->
<!ELEMENT get-sessions EMPTY>
<!ATTLIST get-sessions
   user-name CDATA #REQUIRED
   password CDATA "guest">

<!--
Response: session-list
A session is described by its session-id. We also send over a more human-readable
name
-->
<!ELEMENT session-list (session+)>
<!ELEMENT session EMPTY>
<!ATTLIST session
   session-id CDATA #REQUIRED
   session-name CDATA "Default session">

<!--
Request: get-collections
gets a list of collections on the server.
-->
<!ELEMENT get-collections EMPTY>

<!--
Request: collection-list
a list of collections on the server.
a collection is described by a list of the of the query paradigms which can be used for
querying it, as well as an ID and its human-readable name.
This means, you do not have to index all collections using all the methods you want to
propose to the server.
-->
<!ELEMENT collection-list (collection*)>
<!ELEMENT collection (query-paradigm-list?)>
<!ATTLIST collection
   collection-id CDATA #REQUIRED
   collection-name CDATA #REQUIRED>

<!--
Tag: query-paradigm
arises both in algorithms and collections: this describes the kind of query which can be
performed with this algorithm/collection
-->
<!ELEMENT query-paradigm-list (query-paradigm*)>
<!ELEMENT query-paradigm EMPTY>
<!ATTLIST query-paradigm
   query-paradigm-id CDATA #REQUIRED>

<!--
Request: get-algorithms
gets a list of algorithms usable for one collection
-->
<!ELEMENT get-algorithms EMPTY>
<!ATTLIST get-algorithms
   collection-id CDATA #IMPLIED
   query-paradigm-id CDATA #IMPLIED>

<!--
Response: algorithm-list
returns a list of algorithms for a given collection on the server
-->
<!ELEMENT algorithm-list (algorithm*)>

<!--
Tag: algorithm
An algorithm can contain other algorithms, optionally a property sheet, optionally a query
paradigm list optionally an "allows-children" specification
-->
<!ELEMENT algorithm (algorithm*,property-sheet?,query-paradigm-list?,allows-children?)>
<!ATTLIST algorithm
   algorithm-id CDATA #REQUIRED
   collectiom-id CDATA #REQUIRED
   algorithm-name CDATA #REQUIRED
   algorithm-id ID #REQUIRED
   algorithm-type CDATA "adefault"
   collection-id CDATA "cdefault">

<!--
Tag: allows-children
This tag specifies for an algorithm what kind of algorithms can be children of this algorithm.
no specification ) allows no children.
-->
<!ELEMENT allows-children (query-paradigm-list?)>

<!--
Request: get-property-sheet
get the property sheet for an algorithm
-->
<!ELEMENT get-property-sheet EMPTY>
<!ATTLIST get-property-sheet
   algorithm-id ID #REQUIRED>

<!--
Request: begin-transaction
begins a transaction
-->
<!ELEMENT begin-transaction EMPTY>
<!ATTLIST begin-transaction
   transaction-id ID #REQUIRED
>
<!--
Request: end-transaction
ends a transaction
-->
<!ELEMENT end-transaction EMPTY>
<!ATTLIST end-transaction
   transaction-id ID #REQUIRED>

<!--
Request: configure-session
configures the session by giving an algorithm
-->
<!ELEMENT configure-session (algorithm)>

<!--
Tag: property-sheet
Basic idea: send a property sheet to-
gether with a specification
what should be the XML out-
put coming back. Useful for
configuring your database.
-->
<!ELEMENT property-sheet (property-sheet)*>
<!ATTLIST property-sheet
   property-sheet-id ID #REQUIRED
   property-sheet-type (
     multi-set
    |subset
    |set-element
    |boolean
    |numeric
    |textual
    |panel
    |clone
    |reference) #REQUIRED
   caption CDATA #IMPLIED
   visibility (popup|visible|invisible) "visible"
   send-type (element
    | attribute
    | attribute-name
    | attribute-value
    | children
    | none) #REQUIRED
   send-name CDATA #IMPLIED
   send-value CDATA #IMPLIED
   min-subset-size CDATA #IMPLIED
   max-subset-size CDATA #IMPLIED
   from CDATA #IMPLIED
   step CDATA #IMPLIED
   to CDATA #IMPLIED
   auto-id (yes|no) #IMPLIED
   auto-id-name CDATA "id"
   defaultstate CDATA #IMPLIED>
   
<!--
Tag: algorithm
An algorithm will be either an empty element with attributes (add some at your will, it
will talk with your server anyway, and this is the server which sent the property sheet), or
a tree of algorithms.
What is the use of this? Think of conguring meta queries. Together with properties
you get a powerful tool.
-->
<!ELEMENT algorithm (algorithm*)>

<!--
Beginning and renaming sessions
We want to give the user the possibility to save the current state into "sessions". This
might be useful in the case that a user has several classes of goals which s/he knows in
advance.
The user can request a new session. S/he can also request a name change for a session.
Ending sessions is implicit: we cannot aord being dependent on the user ending
his/her session in a "nice" way, so we do not tempt programmers to do so
-->

<!--
Interface side
-->
<!--
send the desired feedback method together with a name for the session
-->
<!ELEMENT open-session EMPTY>
<!ATTLIST open-session
   user-name CDATA #REQUIRED 
   password CDATA #IMPLIED
   session-id CDATA #IMPLIED
   session-name CDATA #IMPLIED>

<!ELEMENT rename-session EMPTY>
<!ATTLIST rename-session
   session-id CDATA #IMPLIED
   session-name CDATA #IMPLIED>

<!ELEMENT delete-session EMPTY>
<!ATTLIST delete-session
   session-id CDATA #REQUIRED>
   
<!ELEMENT close-session EMPTY>
<!ATTLIST close-session
   session-id CDATA #REQUIRED>
   
<!ELEMENT acknowledge-session-op EMPTY>
<!ATTLIST acknowledge-session-op
   session-id CDATA #REQUIRED>

<!--
Simple user commands (for logging purposes)
(like e.g. back or forward in the command history) (at present the only commands)
-->
<!ELEMENT user-data EMPTY>
<!ATTLIST user-data
   command (history-backward|history-forward) "backward"
   steps CDATA #IMPLIED>

<!--
Request: query-step
At present we provide only query by example, and search for random images (done, if
one sends an empty query-step tag)
-->
<!ELEMENT query-step (user-relevance-element-list?)>
<!ATTLIST query-step
   query-step-id CDATA #REQUIRED
   result-size CDATA #IMPLIED
   result-cutoff CDATA #IMPLIED
   query-type (query|at-random) "query"
   algorithm-id CDATA #IMPLIED>

<!--
Tag: user-relevance-element-list
List of URLs with user given relevances Our way of specifying a QBE for images.
relevances vary from 0 to 1
-->
<!ELEMENT user-relevance-element-list (user-relevance-element+)>
<!ELEMENT user-relevance-element EMPTY>
<!ATTLIST user-relevance-element
   user-relevance CDATA #REQUIRED
   image-location CDATA #REQUIRED>

<!--
Response: query-result
each result image can be accompanied by the user given relevance, as well as the simi-
larity calculated by the program, based on the feature space.
calculated similarities vary from 0 to 1
-->
<!ELEMENT query-result (query-resultelement-list?,query-result*)>
<!ELEMENT query-result-element-list (query-resultelement+)>
<!ELEMENT query-result-element EMPTY>
<!ATTLIST query-result-element
   calculated-similarity CDATA #REQUIRED
   thumbnail-location CDATA #REQUIRED
   image-location CDATA #REQUIRED>

<!--
Error messages.
-->
<!ELEMENT error EMPTY>
<!ATTLIST error
   message CDATA #REQUIRED>
   
   
<!-- End of MRML DTD -->