HML
To export to a HML file
Note. Only records on the current search results page will be exported. Therefore you may need to narrow your results to the selected page, or change the number of records displayed per page, via your Profile | Preferences (the default is 50, the maximum is 500).
Alternatively, the Export | HML section provides additional export options:
HML with Related provides the most comprehensive HML but the standard HML option provides a useful way to look at single records.
The output is displayed in a separate window:
(See HML output for details of the HML structure.)
There are three main parts to a HML document:
The hml root element contains the following top level elements:
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.
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.
This element is only present if the user has selected one or more records. Selected record ids are coma separated.
This element denotes the time and data when the document was written.
*
This element counts the records in the document.
Has a count attribute.
Note. resultCount, recordCount and records/@count*
The record element has two attributes:
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.
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:
This element records the unique id of the current record in the context of the database. This id is auto-assigned
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.
This element records the generated title of a record. Titles are generated using a mask build from details (see below).
When the record was added to the database.
Will be the same as added until a change is made
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:
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.
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 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: Produce online help for Qt applications