 |  | Copyright © 1992, 1997 International Organization for Standardization. All rights reserved. This electronic document is for use during development and review of International Standards. Official printed copies of International Standards can be purchased from the ISO and the national standards organization of your country. | ||
| Next Clause | Previous Clause | |||
Hyperdocument management facilities are required for all uses of HyTime. They include the representation, identification, and accessing of objects, and a hyperdocument interchange format.
Representation facilities for HyTime documents are provided by SGML and are defined in ISO 8879. HyTime requires the use of the SGML formal public identifier feature, but does not otherwise constrain the choice of available SGML options and variants.
The document representation facilities include:
Document type definition capability, including user extensions that can be controlled by the application designer.
Representation of any architectural structure.
Demarcation of information objects, including components of documents, such as elements, attributes, and data content portions.
Ability to include multimedia object formats represented in any notation.
Separation of processing specifications from intrinsic information.
Ability to associate multiple sets of processing specifications ("styles") with element types and individual elements.
Independent transparent entity structure (see 6.1.1.1 Entity structure).
NOTE 79 Within a HyTime hyperdocument, documents and information objects other than the hub document need not be HyTime documents and need not be represented in SGML. For objects that have an internal structure, those structures will only be addressable through HyTime facilities if a grove is constructed for them. An object for which there is no grove can only be addressed by reference to an entity node in an SGML document grove that declares the object as a data entity.
Object identification facilities within HyTime documents are provided by SGML and are defined in ISO 8879. Public identifiers of external documents and information objects must conform to ISO 9070.
NOTE 80 ISO 9070 allows public identifiers to be represented in a variety of formats, including ASN.1 structures and SGML formal public identifiers. The identified objects need not be represented in SGML.
NOTE 81 Forms of public identifier not supported by ISO 9070, such as distributed object references with semantic connotations, can be treated as formal system identifiers (see A.6 Formal System Identifier Definition Requirements (FSIDR)).
Access from the identification of an object to its physical storage is provided by the SGML entity manager component of a HyTime system, which might invoke network processes to retrieve the located data from a remote data base.
NOTE 82 The process is analogous to the role of a reference librarian, who accesses a document mentioned in a citation either by locating it on the library shelves, or by consulting a catalog to find it in another library.
Several HyTime semantics, including hyperlink anchor semantics, activity policy semantics, and scheduling semantics, are applied to referents by referencing constructs (referrers). The referent of any referrer may be in a different object than the referrer. Since no system can be expected to process all of the documents in existence to determine what semantics may have been applied to any given piece of information, it is necessary to specify which documents contain all the referrers that are needed in order to understand the referents in a given HyTime hyperdocument.
Also, as a HyTime hyperdocument may consist of more than one object, authors must be able to specify what objects need to be present in order to have a complete copy of the hyperdocument.
For these reasons, the number of documents and other information objects that a HyTime system can be expected to regard as a hyperdocument must be finite -- a "bounded object set" (BOS). If the exact set of required objects is not known, there is a potential for incorporating vast amounts of unwanted information and incurring unnecessary delay, expense and inconvenience. HyTime provides facilities for managing bounded object sets. These facilities consist of common data attributes, attributes of the HyDoc element form, and the BOS specification element form (see 6.5.2 HyTime BOS control data attributes and 6.4 HyTime document).
Conceptually speaking, there are three kinds of BOS:
Every HyTime hyperdocument has exactly one "hub" document; processing of the entire HyTime hyperdocument nominally begins with the hub, which is nominally the HyTime document through which entry to the HyTime hyperdocument was gained, that is, the HyTime document with which the processing session begins. The HyTime BOS is the BOS specified (directly and indirectly) by a HyTime hub document. Therefore, the author of a HyTime hyperdocument has control of the set of objects considered to be members of its HyTime BOS. The membership of objects in the HyTime BOS is determined according to rules defined by this international standard regarding the semantics of the boslevel, inbos, and subhub common data attributes, the semantics of the maxbos, boslevel, and bosspec attributes of the HyDoc architectural form, and the semantics of the boslevel and inbos attributes of the bosspec architectural form. The objects in a HyTime BOS are also classifiable by HyTime hyperdocument authors as having foreground or background priority.
The application BOS is the BOS intended by the software programmer of a HyTime system to constitute the hyperdocument.
NOTE 83 The concept of the application BOS includes an implicit recognition of the fact that some systems may be deliberately designed to process hyperdocuments which differ, in terms of the set of member objects used, from the HyTime BOS. For example, there may be systems that regard all documents referenced by World Wide Web-style URLs that appear in the hub document to be in the BOS, even when the documents referenced by such URLs are not specified by any corresponding entity declarations anywhere in the hyperdocument.
NOTE 84 If no value is specified for the boslevel attribute of the hub document's HyDoc document element, there is no HyTime BOS and, of necessity, the application BOS governs the assembly of the effective BOS.
The BOS consisting of all the objects that at any given point have been successfully and fully integrated into the hyperdocument being processed.
NOTE 85 The concept of the effective BOS is an implicit recognition
of the fact that some objects that the hyperdocument author regarded
as necessary (and which are therefore in the HyTime BOS), and/or which
the system programmer regarded as necessary (and which are
therefore in the application BOS), may not be retrievable or
integratable into the hyperdocument with complete success. Much of
this international standard is primarily concerned with the semantics
of a set of objects that has been fully and successfully integrated
into a hyperdocument, and therefore it is primarily concerned with the
effective BOS, irrespective of how the membership in the effective BOS
was determined, or which members of the HyTime and/or application BOSs
had to be left out or exceptionally included for any reason. As the HyTime BOS is the only BOS whose membership is defined by
this international standard, and as the HyTime BOS is the only
standardized indication of what objects an author intends the
hyperdocument to consist, there is reason to expect that, in many
applications and instances in which HyTime hyperdocuments are
processed, the application BOS and the HyTime BOS will be identical,
and, therefore, barring mishap, the effective BOS will be the HyTime
BOS.
This international standard does not provide means for expressing application BOSs or effective BOSs; it provides such means only for HyTime BOSs.
NOTE 86 Of course, nothing prevents the expression of an application BOS or an actual effective BOS as a HyTime BOS in a HyTime document.
Except possibly for addressing information needed to refer to portions of the content of documents that are not present in the effective BOS, a HyTime system is not required to have any knowledge of the content of documents and objects that are not in the effective BOS. If a HyTime system obtains access to the content of such documents, such as when resolving the addresses of anchors within such documents, such documents must first be added to the effective BOS. Insofar as HyTime processing semantics and the system's requirements dictate, a HyTime system maintains knowledge of and access to all the referents within the effective BOS of all referrers within the effective BOS.
NOTE 87 In other words, the effective BOS is the set of information
objects for which a HyTime system has actually assumed
responsibility at any point in time. The effective BOS concept -- the
idea that a system has only a finite number of objects for which
it is responsible -- makes references with bidirectional semantics
from and to external documents both practical and scalable. For example, if the scheduling module is supported, the effective
BOS contains all the fcs elements corresponding to all the FCSs for
which the system is responsible, and all the scheduling constructs
known to affect them. Even if an fcs element exists in the effective
BOS, any schedules, batons, or wands that are directly scheduled or
projected onto the logical FCS to which it corresponds will have no
effect unless they, too, are included in the effective BOS. (In other
words, the system is not required to know about anything affecting
FCSs that is not in the effective BOS.) Schedules, batons, and wands
that only affect FCSs that correspond to fcs elements that are not
present in the effective BOS have no effect unless and until the
documents in which such fcs elements are declared are added to the
effective BOS. (Systems may support the addition of documents
containing such referenced fcs elements to the effective BOS even when
they are not members of the HyTime BOS; such added objects are, by
definition, members of the application BOS.) For another example, if the activity option of the base module is
supported, the effective BOS determines the effectivity of activity
policies. Actrules in the effective BOS are in effect for the objects
in the effective BOS that they govern, according to the policies that
are also in the effective BOS. For a third example, in the case of hyperlinks, the system
knows all the anchors within the effective BOS of all the links within
the effective BOS. It need not know the anchors of any links if those
anchors are not in the effective BOS, and it need not know any anchors
that are the anchors of links that are not in the effective BOS.
If a link is traversed to an anchor outside the effective BOS,
the object containing that anchor must first be added to the effective
BOS. Some systems may do this without any special user
interaction; others may warn users that, for example, the effective
BOS will thereafter contain an object that was not specified in the
HyTime BOS.
NOTE 88 Adding a document to the effective BOS does not necessarily mean adding that document's HyTime BOS to the effective BOS, as if the added document were itself the hub document. Only the hub document specifies how the HyTime BOS is to be derived, and, in any case, some systems may ignore even the HyTime BOS.
A HyTime bounded object set ("HyTime BOS") can be determined automatically by a HyTime system by "discovering" an "entity tree", using the SGML document entity of the hub document as the root. The entity tree includes external document, subdocument, and data entities declared in the hub document, then external entities declared in those entities, and so on. Only entities declared in "external identifier" parameters of markup declarations will be discovered. Therefore, if external references are made from data content using a notation-specific form of reference, such entities will not be included in the HyTime bounded object set unless the document originator also creates entity declarations for them.
NOTE 89 This international standard does not require systems to
assemble BOSs according to any particular methodology or order.
However, purely as an example, it may be useful to consider the
following methodology for determining the membership of objects in a
HyTime BOS. (Considerable optimization of the performance of
interactive HyTime hyperdocument applications can be achieved by
judicious use of foreground and background priority.
For clarity, the following methodology does not take the possibility
of background priority into account.)
Determine the unadjusted HyTime BOS.
For each entity declared in the hub document
entity whose subhub attribute's value is subhub, complete a HyTime BOS
assembly process exactly like the one being done for the hub document.
This should be done recursively if subhubs declare entities as
subhubs. The HyTime BOS of each subhub document entity is added to
the tentative HyTime BOS of its parent document entity. Do not regard
as a subhub any entity whose parent is not a hub or subhub, even if
its parent declares it using a subhub attribute with a value of
"subhub". Discover the entity tree of which the SGML hub (or
subhub) document entity is the root, adding each entity to the
tentative HyTime BOS. Ignore all entities whose subhub attribute's
value is "subhub" unless their parent entity was neither a hub nor a
subhub, as they have already been taken into account in the previous
step. During the entity tree discovery process, do not exceed the
number of recursions specified by the smaller of (i) the value of the
maxbos attribute of the hub's (or subhub's) document element's maxbos
attribute, or (ii) the value of the boslevel common data attribute
(which may have a default value specified by the boslevel attribute of
the hub's [or subhub's] document element's boslevel attribute) of the
corresponding entity declaration in the hub document entity. If,
during the entity tree discovery process, an entity declaration's
inbos attribute has a value of "inbos", include it, too, in the
tentative HyTime BOS even if doing so exceeds the maxbos or relevant
boslevel specification.
Apply all adjustments specified by bosspecs referenced by the bosspec attribute of the document element of the hub (or subhub) document whose inbos attribute's value, if any, is not "notinbos". This may require additional entity tree discovery processing. If the value of the inbos attribute of a bosspec is "inbos", add all the objects addressed by the content and boslevel attribute of the bosspec to the tentative HyTime BOS.
Apply all adjustments specified by bosspecs referenced by the bosspec attribute of the document element of the hub (or subhub) document whose inbos attribute's value is "notinbos". Whatever objects remain constitute the HyTime BOS.
Limits can be placed on the depth of the HyTime BOS entity tree discovery process by the maxbos attribute of the hub document's document element, by the boslevel common data attribute on entity declarations, and by bosspec elements referenced by the bosspec attribute of the hub document's document element.
The HyTime BOS, if specified, represents the author's intentions with respect to the objects that participate in the hyperdocument. However, a system may use either an application BOS or a HyTime BOS to guide the assembly of its effective BOS. Moreover, it is possible for systems to exclude, voluntarily or involuntarily, some of the member objects of the HyTime BOS from the effective BOS, and/or to include objects in the effective BOS that are not members of the HyTime BOS. One possibility is for the system to use the HyTime BOS as a starting effective BOS, but to allow entities to be added and deleted by the user. (By definition, once the effective BOS is no longer the same as the HyTime BOS, the effective BOS is an application BOS.) Therefore, the question of whether the system is presenting the hyperdocument as the author intended at any given point is an information accuracy issue.
It is possible for the effective BOS to be neither an application BOS nor a HyTime BOS, if the intended HyTime or application BOS cannot be fully assembled due to environmental processing constraints, such as the lack of a network connection. It is also possible for a system to regard a document other than the session-start document as a hub document, and to use the HyTime BOS that it specifies in some fashion.
All three types of BOS (HyTime, application, and effective) always contain, at minimum, a hub document.
A "hyperdocument interchange format" is a data structure that combines the separate documents and information objects of a hyperdocument into a single "data stream" for interchange. The hyperdocument interchange format recommended for use with HyTime is the SGML Document Interchange Format (SDIF) defined in ISO 9069.
NOTE 90 This International Standard does not constrain the interchange format for renditions of a HyTime hyperdocument, for which an application may choose to use a format optimized for transmission or interactive presentation.
SDIF is independent of the architectures and applications of the information objects that it carries. A single SDIF implementation could therefore be capable of supporting all HyTime applications.
An SDIF data stream can carry any bounded object set, and is not strictly limited to HyTime hyperdocuments. In particular, the interchange data stream could include all of a single hyperdocument, a part of it, and all or part of other documents as well. In all cases, SDIF preserves the demarcation of documents and information objects, and can preserve the entity structure in which they existed in the originator's environment.
The process (application or HyTime engine) that determines the BOS submits the names of the entities that comprise the BOS to the SDIF packer program. The SGML document entity of the hub document, if present, is identified to SDIF as the "main" document. The packer creates an "entity descriptor" in the SDIF data structure for each entity. The descriptor includes the entity data. However, the SDIF packer will create a "cross-reference" entity descriptor if the external identifier of an entity duplicates that of another, in order to avoid duplicating the data.
NOTE 91 The SDIF "packer" process that creates the data stream is aware of the entity declarations, and therefore of the notations (media types) of the entities. In a communications environment it would be possible to use this information to optimize bandwidth allocation and routing for different types of media when transmitting the hyperdocument.
HyTime provides a means of including the data of several entities within the storage of a single "container" entity, thereby allowing the use of interleaving and other techniques that optimize access to multimedia data. The data of the container entity is stored in its entity descriptor, while the entity descriptors of the contained objects are cross-references to the container (see A.6.3 Containers).
An SDIF unpacker receives an SDIF data stream and stores its contents in the storage media of the receiving system. Alternatively, it could act as a "handler" or "reader" service, invoked by the SGML entity manager, that unpacks SDIF dynamically as required by an application program.
If necessary, the SDIF unpacker modifies the system identifiers of the markup declarations to be consistent with storage addresses in its environment. When it encounters an entity declaration for which there is no entity descriptor (because, e.g., it is outside the bounds of a HyTime BOS), it modifies the system identifier to show that the entity is not available. An attempt by an application to access that entity will result in an appropriate message.
NOTE 92 An SDIF unpacker implementation could choose to retain the sender's original external identifier, together with a "not received" indication and the date and time of the SDIF receipt. Later, if an unsuccessful attempt is made to access the entity, the entity manager could give the application the option of contacting the sender to request a copy, or trying to access it directly on the sender's system.
| Next Clause | Previous Clause |
| Copyright © 1992, 1997 International Organization for Standardization. All rights reserved. This electronic document is for use during development and review of International Standards. Official printed copies of International Standards can be purchased from the ISO and the national standards organization of your country. | |
HTML generated from the original SGML source using a DSSSL style specification and the SGML output back-end of the JADE DSSSL engine.