HML Syntax

The Header (or HML) Element

The hml root element contains the following top level elements:

database

This element allows the source database to be identified. This is useful both when the HML has been separated from the source application and also when transforms require clickable links to be displayed that return the user to another record within the same db. The id attribute provides the unique database id.

query

The query element is all attributes. The w attribute should always have the value all and can be ignored by most users.

The depth attribute shows the maximum loaded depth for the current context (see depth below)

The q attribute can take many forms. It may be the name of a saved query or it may be a list of ids or a more complex query string. This attribute along with the db attribute (which repeats the database element) allows recreations of the HML document.

The layout attribute reflects layout options selected by the user. This attribute is under development and may change form.

selectedIDs

This element is only present if the user has selected one or more records. Selected record ids are coma separated.

dateStamp

This element denotes the time and data when the document was written.

resultCount

recordCount

This element counts the records in the document.

records

Has a count attribute.

The Record Element

The record element has two attributes:

depth

This attribute expresses the level a given record has within the overall result-set. If a book for example was at level 0 the author and publisher records would be at level 1. Level 1 records may or may not be present depending on whether the user has loaded any lower levels. There can be a fractional level of 0.5 or 1.5 etc and this is used when relation records are present as they are regarded as bridging between levels.

visibility

This attribute can have the value of viewable or hidden. Hidden records may appear if a given user has access rights. It is often important to view this attribute in the context of the workgroup element described below as visibility is workgroup controlled.

The record element is repeated as a third level element (/hml/records/record) and contains the following elements:

id

This element records the unique id of the current record in the context of the database. This id is auto-assigned

type

This element records the record type. Attributes type and conceptID uniquely identify the record type first in the context of the database and second in the broader context of all H3 databases. The number before the dash represents the source database id. It is strongly recommended that any transforms use this conceptID so as to make them portable to other databases.

title

This element records the generated title of a record. Titles are generated using a mask build from details (see below).

added

When the record was added to the database.

modified

Will be the same as added until a change is made

workgroup

This element records any workgroup Ownership for the record. The id attribute records the auto-assigned, unique id for the workgroup. The visibility attribute on the record element determines the privacy settings of the record.

The following elements may be repeated:

detail

All records are composed of details. These can be simple or complex. Each detail element has four attributes. The first group – id and conceptID – denote the locally unique detail id and the broader Heurist detail id. Once again we recommend that all transforms use the conceptID where possible to make code portable between databases.

The second detail group – type and name – denote the global and local label given to the detail.

Detail elements can contain complex sub elements. For example thumbnail image type details encapsulate a file element with appropriate metadata such as mime type and file size as well as the URL of the file itself. Some details include references to XML files which are expanded in place within a content element with a type attribute (e.g. <content type=”TEI”>). This behaviour allows – for example – TEI document records to be rendered as readable text with the appropriate XSL.

reversePointer

A reverse pointer should be interpreted as meaning “a record with the id x references this record”. For a book record there should for example be a reverse pointer record for the author.

These elements are similar in structure to detail records but encapsulate only a record id. The assumption made is that if the HML is appropriately expanded then an xpath statement of the form /hml/records/records[id=x] will find the appropriate record node and its sub elements.

relationship

Relationship elements are broadly similar to reverse pointer records but relationship records in H3 add additional modifiers to simple pointers. Relationships are actual records that have a pointer to the source and target records and also include a relationship type. The type attribute provides the relationship type and the inverse attribute provides the inverse of the type. The relatedRecordID establishes the target record id for use in the same way as there reversePointer value.

Created with the Personal Edition of HelpNDoc: Easily create HTML Help documents