The xbel element defines the top-level data structure stored in an XBEL instance. It may contain optional title, info, and desc elements, followed by any number of elements from nodes.mix. This is similar to the folder element, but it may not be nested and carries different attributes.

Attributes. The xbel element carries a version attribute which has a fixed value that specifies the version of the XBEL DTD. Other attributes indicate the similarity to the folder element.

Processing Expectations. The xbel element is in many ways similar to a folder element, but may not be ``folded.'' Auxillary information, such as an optional title element, may be shown in a substantially different way than for folder in a user interface.

The title element is used to mark the title associated with the immediately enclosing element. It is used for the xbel, folder, and bookmark elements. This element is always optional and may contain only character data.

Processing Expectations. Software which presents bookmark information to the user in any form should use the content of this element to identify the resource to the user. Additional information may be needed to make the identification unambiguous.

Applications may use the text of the \element{title} during search operations.

Rationale. Many Internet resources are described by a short title, often displayed by the bookmarking facilities. Storing the title allows a significant improvement in user interface responsiveness when compared to retrieving the resource to reload the title. Title storage is the approach taken by all browsers known to the XBEL designers.

The desc element is used to store a human-readable description of the enclosing element. For a folder or the xbel element, this may be used to more thoroughly explain the subject of the bookmarks stored in the collection and why they may be interesting. For a bookmark, a summary of the resource pointed to by the bookmark may be more appropriate. This element is always optional and may contain only character data.

Processing Expectations. The content of this element may be displayed to a user requesting more information on the folder or bookmark containing the description. In the case of a bookmark, this can be used before actually making a request over the network to retrieve the resource.

Applications may use the text of the desc during search operations.

Rationale. Many Internet browsers support simple annotation of bookmark data with human readable text. This element is required to support exchange of this data.

The info element is used to store metadata related to the immediately enclosing element. The intended use is for info to store a series of metadata elements, each of which ``belongs'' to some application. An ``application'' in this sense may be either a program, such as a specific Internet browser, or a more general metadata scheme, such as the Dublin Core [dublin-core].

The info element is always optional. If present, it must contain one or more metadata elements.

Processing Expectations. Applications are expected to ignore info elements if they are not able to deal with the contents of constituent metadata elements. Whether or not info elements should be ``passed through'' transparently or removed depends on the purpose of the processing application, but an effort should be made to retain the information whenever the enclosing element is retained, even in a modified form.

Rationale. This element provides a clean way of isolating application-specific metadata from more generally supported constructs within the bookmark data.

The metadata element is used as a container for all auxillary information related to a node which belongs to a single metadata scheme. The specific contents of metadata is highly dependent on the metadata scheme which applies; XML namespaces should be used to identify explicit markup used within the element.

The DTD for XBEL specifies the content model for metadata as EMPTY, but any content should be considered acceptable so long as the XBEL document is well-formed. The use of EMPTY avoids making the DTD too loose; applications which do not validate need not be concerned. Derivative DTDs can define the parameter entity metadata.mix to be the appropriate content model for the application.

metadata elements are always optional. Note that an info element which contains no metadata elements must be removed.

It is expected that namespace attributes will be added to the element to specify the markup defined for the content of the metadata element.

Processing Expectations. Within an info element, each metadata element is required to have a unique value for the owner attribute. Programs which modify the contents of metadata elements should ensure that only one metadata exists for any owner value normally modified by the application within affected info elements. metadata elements for other owners should remain unaffected.

Specific interpretation of metadata content is highly dependent on both the owner and the application, and is not otherwise within the scope of this document.

Rationale. The metadata element is required to support owner identification. It is entirely reasonable for multiple owners of data to share a document type for their information, but otherwise require separate processing. The Resource Description Framework provides an example of an approach which would require multiple applications to share a namespace [w3c-rdf-syntax][w3c-rdf-schema]. Some additional form of ownership identification is required to ensure processors can avoid destroying each other's data.

The folder element is the element used to support hierarchical data organization. It is the only element type which is allowed to nest within itself.

This element may contain optional title, info and desc elements. After this, any number of elements from nodes.mix are allowed.

Processing Expectations. User interfaces should display folder elements as collapsing lists, allowing the user to display or hide the contents of the element on demand. Appropriate behavior outside of user interfaces is expected to be application specific.

Rationale. The folder element may be used to represent hierarchical relationships within a collection of bookmarks, as deployed in current Internet browsers. The toolbar attribute is needed to support the ``Personal Toolbar'' information from Netscape Navigator.

The separator element can be used to separate bookmarks within a collection in a non-hierarchical fashion. It may be used within a folder or the xbel element.

Processing Expectations. The presence of this element may be represented by displaying a horizontal line or vertical whitespace in an interactive user interface or printed representation.

Rationale. A simple separator is required to support the bookmark structures of existing Internet browsers.

A bookmark element is used to store information about a specific resource. This element may contain the optional elements title, info and desc.

Processing Expectations. In a user interface, bookmark should typically be represented by the contents of the title element, if present. The representation of the bookmark should be ``hot,'' allowing traversal to the referenced resource by the user. Additional information on the resource, such as the description given in a desc element, should be available to the user on demand.

Outside a user interface, processing may be too application-specific to discuss here.

Rationale. The use of a single structured element type to represent external resources simplifies processing while allowing a rich set of information to be maintained on each resource.

Processing Expectations. Software which presents bookmarks in a user interface should distinguish aliases from other bookmarks visually, but otherwise allow examination of the referent transparently. Netscape Navigator does this by presenting the bookmark title in an italic font; the appropriate visual distrinction is likely to be dependent on other aspects of the user interface.

Outside of user interface considerations, treatment of aliases is application-specific. However, some guidance may prove useful. When encountering an alias, an application should only need to traverse the alias and process the referent if that referent would not otherwise be processed, otherwise, the alias may usually be ignored. This should become an issue only when the application is processing a portion of the bookmark hierarchy rather than the complete tree.

Rationale. Netscape Navigator and Microsoft Internet Explorer bookmarks can include ``aliases'' to other nodes in the hierarchical structure. Navigator supports only aliases to bookmark nodes, while Internet Explorer also supports aliases to folders.

Navigator's format simply adds the attribute aliasid to nodes which are referred to be aliases, and the attribute aliasof to the actual alias. All other information is duplicated for each alias of the primary bookmark entry. XBEL uses a distinct element and the ID/IDREF mechanism provided by XML to avoid redundency and support validation.

The nodes.mix entity lists the element types which may be used to form the nodes of the hierarchical data structure described by an XBEL instance. This entity species a mixture of bookmark, folder, separator and alias elements.

This entity is used to define attributes for element types which hold the real content of the bookmark data. It is used on the bookmark and folder elements. It defines the optional added and id attributes.

This entity defines the attributes which are available on elements which refer to specific resources. In XBEL 1.0 and 1.1, this is only used on the bookmark element. It defines a required href attribute and the optional attributes modified and visited.