 the Internet is well known. This is easy as long as whole documents are sent, including their DTDs, SGML declarations, all entities, etc. But many SGML documents are too large to be managed by shipping them in their entirety when only a portion may be needed.
Many documents are megabytes in length, even excluding all the graphic, video, and other entities a document may reference. Transferring such a document can take too long for real-time access. Even after a document arrives, it may take too long to parse it and get to the desired part. If the user asked to look at chapter 20, one must parse 19 whole chapters before seeing it. With hypertext documents, one also can't afford to include every document the first one references, when the user will likely follow only a few of the links.
The obvious solution is to not send it all, but instead send things as they become needed. The goal of this resolution is to define a way senders can send small parts of an SGML document at need, without also having to send everything up to the part needed. This can be done regardless of whether the parts are entities or not, and the parts can either be viewed immediately or accumulated for later use, assembly, or other processing.
The SGML standard has some constructs that can be used to address these issues in certain situations. External text entities can be used, but they generally do not contain the necessary context information. Some tools and implementations, however, may be able to make use of such entities without the explicit context information. Furthermore, 8879 defines SUBDOC entities that are self-contained in terms of context (they are complete documents), but each SUBDOC forms its own ID name space and each must have its own DTD. Though some fragment applications can be addressed using the constructs already available in 8879, the constructs in the standard were not seen as being sufficient for all applications that need to use fragments. This Resolution was developed to provide an interoperable solution for fragment applications when the techniques of 8879 are insufficient.
The challenge is that an isolated element from an SGML document may not contain quite enough information to be parsed correctly. This resolution enables senders to provide the remaining information required so that systems can interchange any SGML elements they choose, from books or chapters all the way down to paragraphs, tables, footnotes, book titles, and so on, without having to manage each as a separate entity or having to risk incorrect parsing due to loss of context.
A sender can send a fragment that consists of any element or any sequence of SGML data that constitutes “mixed content” or “element content” drawn from an SGML document. Most commonly this means a sequence of contiguous sibling elements, but processing instructions, comments, whitespace, and certain other SGML constructs are also permitted. Any element that begins within the fragment must end there as well, and any element that ends in the fragment must also start there (this constraint is sometimes called “being synchronous”).
The fragment sent can be parsed correctly at the recipient end to produce precisely the same ESIS (SGML structure and content information) that the sender got when it parsed the fragment in its complete document context.
All capabilities of Basic SGML documents (except shortrefs) can be used in any fragment so sent, as well as variant capacities and quantities, as well as many variant delimiters and name characters.
Fragments can be sent exactly as they occurred in the original SGML data. Because they need not be changed in any way, it is possible to authenticate or validate that they have been received intact, and it is possible for users to cache them.
some mechanisms for associating this information with a fragment.
Conceptually, a sender examines a fragment to be sent and, using the notation defined in this Resolution, constructs a fragment context specification. The object representing the fragment removed from its source document is called the fragment body. The sender sends the fragment context specification and the fragment body to the recipient. The storage object in which the fragment body is transmitted is call the fragment entity. (In some packaging schemes, the fragment context specification may also be embedded in the fragment entity.) The recipient processes the fragment context specification to determine the proper parser state for the beginning of the fragment and uses that information to put the SGML parser into the right state to be able to parse the fragment. The fragment body itself can then be parsed normally.
certain changes from the concrete syntax of Basic SGML documents to the capacities, quantities, delimiters, and name characters are permitted, and the FORMAL feature can be either YES or NO.
Variant delimiters and name characters may be used to the extent that they do not introduce conflicts with the delimiters required by this resolution. For example, accented or wide characters may be used freely, but the specific characters number sign (#), single (') and double (") quotation marks, parentheses (()), equal sign (= ), and whitespace may not be added to the permitted SGML name characters because they could conflict with the use of those characters by this resolution.
A fragment context specification uses an extremely simple formal syntax which is chosen (a) to prevent delimiter conflicts if placing a fragment context specification inside an SGML file; (b) to ease the task of parsing fragment context specifications either with standard parser-generator tools or with handwritten programs; and (c) to reflect that a fragment context specification is information about SGML data, not SGML data itself. Though SGML syntax itself was considered as a possible syntax for the fragment context specification language, it was rejected on the basis of not being the best language for our purposes for a number of reasons, including complexities with delimiter conflicts, escaping issues, minimization, issues of being able to embed a string using SGML syntax within an SGML document, and so on.
Six delimiter characters are used in fragment context specifications, and they are shown as quoted literals in the grammar below. They have the same values regardless of what SGML declaration applies to the fragment itself (and its document context). Therefore variant concrete syntaxes in which those delimiter characters are added to the list of SGML name characters (LCNMSTRT, UCNMSTRT, LCNMCHAR, and UCNMCHAR) may not be used with this specification (variant concrete syntaxes that do not introduce such conflicts can be used freely).
Literals in the grammar shall be recognized without regard to case distinctions. Whitespace characters, represented in the grammar as “s”, include space, tab, form feed, carriage return, and line feed.
* and + are used throughout, not only at the lexical (lex) level. They indicate that the preceding token or sub-rule may be repeated; + indicates that at least one instance is required. Square brackets are also used as in lex (an initial “^” negates the list of permitted characters).
All characters other than the null character and the delimiters and whitespace already discussed are permitted as name characters in fragment context specifications.
global   : "(" s* item s* ")"
context  : "(" s* "CONTEXT" s+ elemspec+ s* ")"
| "SOURCE" s+ external_id locator?
external_id : "PUBLIC" s+ value (s+ value)?
locator  : node (s+ dataloc)?
node     : s+ nameloc (s* treeloc)?
nameloc  : "(" s* "ID" s+ name s* ")"
treeloc  : "(" s* "TREELOC" (s+ number)+ s* ")"
dataloc  : "(" s* "DATALOC" s+ number (s+ number)? S* ")"
revalue  : "AFTERSTARTTAG" | "AFTERDATA" | "AFTERRSORRE"
| "PENDINGAFTERRSORRE" | "PENDINGAFTERMARKUP"
elemspec : gi (s+ rep)? (s+ elemprop)* s* "(" s* elemspec* s* ")"
value    : "\'"[^']*"\'"
(SOURCE SYSTEM "http://xyz.com/books/draft/b.sgm"
All items shall be used with the meanings explained in this section; the order in which they are specified is insignificant. It is an error to specify any item other than CURRENT, COMMENT, SOURCE, or an extension more than once. Should such an error be encountered, the last value specified shall be applied.
For correct processing, certain information must definitely be available to the recipient. Therefore a sender must either send those items, send references to them, or have reason to believe that the recipient already has them or knows how to find them. Such items include the SGML declaration, and all markup declarations needed for correct parsing. Few other items are needed except when specific SGML capabilities are actually used: CURRENT items are only needed if #CURRENT attributes occur, attributes and sibling information are only needed for particular recipient processing such as auto-numbering or other formatting, and so on.
If SGMLDECL specifies the token WITHSOURCE, the SGML declaration should be included at the beginning of the storage object indicated by the SOURCE item's external id.
If SGMLDECL specifies the token WITHFRAGMENT, the SGML declaration should be included at the top of the fragment entity itself (except that it must follow the fragment context specification if one is embedded at the top of the fragment entity).
If the SGMLDECL item is omitted, the fragment-aware processor shall start to process the doctype declaration (as specified implicitly or explicitly via the DOCTYPE item). If an SGML declaration is found at the top of it, it shall be