 |  | 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 | |||
A.6 Formal System Identifier Definition
Requirements (FSIDR)
A document indicates the presence of formal system identifiers by using the APPINFO parameter of the SGML declaration and/or the other facilities described in this sub-clause.
In describing these facilities, it is frequently necessary to distinguish between the storage object in an FSI that is under discussion, its associated entity, and the entity and storage object in which the FSI occurs. The following terms are used:
The storage object under discussion. It is specified in an FSI.
The entity whose declaration contains the specified storage object's FSI, or caused that FSI to be accessed from a catalog.
The storage object in which the FSI occurs. If the FSI is in a catalog entry, it is the catalog storage object.
The entity in which the declared entity's declaration occurs.
The storage manager of the specified storage object.
The storage manager of the current storage object.
To determine when formal system identifiers are in use, the APPINFO parameter of the SGML declaration is parsed as a space-delimited sequence of tokens. Potential use of one or more storage managers defined in accordance with these requirements is indicated by specifying the keyword "FSIDR" as one such token. The keyword indicates the potential presence in one or more DTDs or LPDs of a formal system identifier (FSI) declaration that conforms to these formal system identifier definition requirements. The use of the APPINFO parameter to indicate the use of formal system identifiers is optional.
NOTE 502 The use of APPINFO serves to declare the use of formal system identifiers within SGML declarations. However, it is sufficient to enable formal system identifier processing to declare the use of formal system identifiers with the FSIDR processing instruction within DOCTYPE declarations.
The format of the token is:
FSIDRThe token can also specify the name of the FSI declarations in the document's DTDs or LPDs if it is other than "FSIDR". The format is:
FSIDR=FSIUsedwhere "FSIUsed" is replaced by the actual FSI declaration name.
An FSI declaration identifies one or more storage manager notations used in system identifiers. System identifiers in which such notations occur are known as "formal system identifiers". There can be only one FSI declaration in a DTD or LPD.
Syntactically, the FSI declaration is a processing instruction (PI), not an SGML markup declaration. In the template below, it is shown in the reference concrete syntax. In use, the SMName-list parameter must be replaced by one or more storage manager names (SMName) declared as notation names, separated by SGML s separators (white space). It is a reportable error if the system's fsidd does not declare a notation for each SMName specified.
An optional FSIDefDoc parameter can follow the SMName-list parameter, separated from it by a ts. In use, the external-id in the template is replaced by the identifier for the fsidd that defines the SMs used in this document. The parameter can be omitted when the system's only (or default) fsidd is used.
In the (admittedly unlikely) event that a document contains informal system identifiers that appear to be FSIs, and the smalias option is supported, an SMName can be accompanied by an alias that will be used in FSIs in its place. The format is:
SMName=SMNameAliaswhere "SMNameAlias" is replaced by the actual name to be used for that storage manager in the FSIs in the document.
Following the initial character string of "IS10744 ", the declaration name is the following character string, up to the first ts separator. The name is always "FSIDR" in meta-DTDs. It should also be "FSIDR" in DTDs or LPDs, but provision is made for changing it in the The name is always "FSIDR" in meta-DTDs. It should also be "FSIDR" in DTDs or LPDs, but provision is made for changing it in the APPINFO parameter of the SGML declaration, if necessary, to avoid the (admittedly unlikely) possibility of conflicts when retrofitting FSIs to a document that already has PIs that begin with "IS10744 FSIDR ". The declaration name is subject to upper-case substitution if the SGML declaration of the client document specifies general upper-case substitution.
<!-- FSI Storage Managers Declaration -->
<!-- TEMPLATE FOR PI IN DTD, LPD OR DERIVED META-DTD -->
<?IS10744 FSIDR SMName-list FSIDefDoc="external-id" >A formal system identifier consists of a sequence of one or more storage object specifications (an "SOS sequence"). The characters resulting from the resolution of each SOS are concatenated in the order of the sequence and comprise the characters of the entity.
The reference concrete syntax is used for recognition of SOSs in FSIs, both within and outside of SGML documents.
An SOS start-tag is recognized by the occurrence of a start-tag open delimiter followed immediately by a declared storage manager name (see A.6.4.2 FSI declaration) followed either by an SGML "s" separator or a tag-close delimiter.
NOTE 503 SGML numeric character references are recognized in the attribute value literals and content (SOIs) of an SOS. They can be used to avoid false delimiter recognition.
Record starts and record ends are handled in an SOI as they are handled in syntactic content in SGML.
NOTE 504 In practice, this rule means that record starts are deleted from the SOI and that a record end immediately after an SOS start-tag or at the end of an SOI is also deleted.
When the alternative SOS sequence (altsos) option is supported, there can be more than one SOS sequence, separated by vertical bars. An end-tag is required before the vertical bar to avoid ambiguity as to whether the vertical bar is part of the SOI. All the SOS sequences are expected to yield the identical character sequences. The system is free to choose the most convenient.
When the entity usage (entuse) SM is declared (see A.6.6 Entity usage attribute definitions), the FSI can optionally begin with an entuse start-tag, which can be used to specify attributes that apply to all of the entity. The entuse start-tag is not part of any alternative SOS sequence; it applies independently of which alternative is selected. There is no corresponding end-tag for the entuse start-tag. The entuse notation is not a storage manager; it is used solely for the purpose of declaring and specifying attributes.
NOTE 505 The structure of an FSI can be summarized as:
fsi = entuse start-tag?,
sos sequence,
( or,
sos sequence)*,
sos sequence = sos+
sos = sos start-tag,
soi,
( sos end-tag|
( etago,
tagc))?
| 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.