Symbian
Symbian OS Library

SYMBIAN OS V9.3

[Index] [Spacer] [Previous] [Next]



Interface management report


Introduction

This page describes a structure for report documents that describe the interface access and status of APIs of a Symbian OS build.

The reports are in XML, with their structure defined by the DTD given below.

[Top]


Report DTD


Overview

The report structure consists of meta-information about the report itself, followed by lists of named C++ items with their interface access, status, and other identifying information.

The meta-information identifies the OS for which the report was generated: this includes the OS build number, OS release version number, kit type, and company producing the kit.

Items are used in a nested way, so that levels of nesting reflect the C++ scope: e.g. an item element for a member function is nested within an item element for the class.

All items have elements that specify their:

Global (unnested) items must additionally specify component and other information, which does not vary at the member level. This consists of:

Functions can optionally have an additional field that reports the link signature of the function.

[Top]


DTD

<!-- IM report document element definition.
This consists of document information, followed by lists of named C++ items
with their IM access and other information -->
<!ELEMENT symbian-interface-doc (doc-info, item+)>

<!-- Document information.
This describes the source of the information for the document. -->
<!ELEMENT doc-info (build, release, kit, owner)>

<!-- OS build number -->
<!ELEMENT build (#PCDATA)>
<!-- OS release version number -->
<!ELEMENT release (#PCDATA)>
<!-- Kit type -->
<!ELEMENT kit (#PCDATA)>
<!-- Company that produced the build -->
<!ELEMENT owner (#PCDATA)>

<!-- Item information .
Records IM access for a C++ item. It's intended to be used in a nested way, so that
levels of nesting reflect the C++ scope: e.g. an item element for a member function
is nested within an item element for the class.

Nested item must specify their name, access, and type (class, function, etc.). Unnested
items must additionally specify component and other information (this does not vary at
the member level.) -->
<!ELEMENT item (name, id, prototype, type, interface-access, interface-status, linksig?, header?, 
    library?, technology?, sub-system?, component?, item*)>

<!-- Item name.
The name does not include the scope: this is implied by the item's nesting. -->
<!ELEMENT name (#PCDATA)>

<!-- Item ID.
A unique ID, an MD5 hash of the item's prototype. This allows simple comparision and
tracking of items by programs. -->
<!ELEMENT id (#PCDATA)>

<!-- Item prototype
This is the text of the item's prototype. Text is useful for human readability. -->
<!ELEMENT prototype (#PCDATA)>

<!-- Item type.
One of: class, function, struct, enum, typedef, macro, enum-member, union, data, namespace -->
<!ELEMENT type (#PCDATA)>

<!-- IM access.
One of: publishedPartner, publishedAll, internalTechnology, internalComponent, internalAll, unspecified  -->
<!ELEMENT interface-access (#PCDATA)>

<!-- IM status.
One of: prototype, interim, released, deprecated, removed, unspecified  -->
<!ELEMENT interface-status (#PCDATA)>

<!-Link signature for a function. -->
<!ELEMENT linksig (#PCDATA)>

<!-- Header file that declares the item. -->
<!ELEMENT header (#PCDATA)>

<!-- Library to link against to use the item. -->
<!ELEMENT library (#PCDATA)>

<!-- Technology -->
<!ELEMENT technology (#PCDATA)>

<!-- Sub-system -->
<!ELEMENT sub-system (#PCDATA)>

<!-- Component -->
<!ELEMENT component (#PCDATA)>

[Top]


Report files

Interface Management reports are included as part of the Release Notes on the CustKit.

Note that not all items are yet IM classified.