ISO/IEC JTC1/SC18/WG8 **N1798**

# ISO/IEC JTC1/SC18/WG8 Document Processing and Related Communication--- Document Description and Processing Languages {#isoiec-jtc1sc18wg8-document-processing-and-related-communication-document-description-and-processing-languages .Heading-0-(nobreak)}

  -------------------- --------------------------------------------------
  **Title:**           Editing Instructions for HyTime TC

  **Source:**          WG8

  **Project:**         JTC1.18.32.2, HyTime

  **Project editor:**  Charles F. Goldfarb

  **Status of          Approved Editing Instructions
  document:**          

  **Requested          For information
  action:**            

  **Date**             21 July 1995

  **Distribution:**    WG8 and liaisons

  **References:**      N1796, 1797

  **Supersedes:**      
  -------------------- --------------------------------------------------

# Editing Instructions for HyTime TC {#editing-instructions-for-hytime-tc .Heading-0}

NOTE: All files referenced in this document are available to WG8 members
from the Project Editor's FTP site. Other interested persons wishing
access should contact their National Body representative to WG8 or the
Project Editor. (E-mail: Goldfarb@InterRamp.com)

Conform the narrative text in PE3.TXT, peanxc3.sgm, peanxd3.sgm to the
formal text in PECAT3.TXT and apply the following editing instructions:

## GENERAL

1\. Consolidate multiple changes to adjacent text into a single larger
replacement where appropriate.

2\. Proof the corrigendum and correct spelling, grammar, and punctuation
while removing errors, ambiguities, and inconsistencies.

## Clause 3

3.42: Say RHEs include RAEs described in annexes C and D.

## Clause 5

New first para to say: HyTime conforms to annex C.

FN 2: Say all formal definitions can be copied; copyright year is
1992,1995

## Clause 6

6.2.4.1: Given a BOS level of N, clarify that SGML text entities
declared at level N+1 are also included in the BOS, as they are part of
the documents (or subdocuments) declared at level N.

6.3: Say how ArcBase in APPINFO references through the ArcBase
declaration to the HyTime support declarations, and point to annex C for
descriptions of the support attributes for all architectures. Point to
7.4.2.3 for a description of hyqcnt. Describe support attributes and
make Notes 75 and 77 conform.

6.4: Delete all text except discussions of boslevel, unmspace, and
docmdu. Say that HyDoc and HyTime identify architectural constructs and
point to annex C descriptions.

6.4: Change Boslevel and unmspace and docmdu to support attributes.

6.4: Add note to the effect that in meta-DTD there is no attempt to
restrict undesireable nesting, that should be done with element type
definitions.

6.5: Say that all-Arc exists and point to its description in annex C.

6.5.1: Delete all mention of id, notation, and HyNames attributes. Add a
specification conforming to Annex C of the default name of the ArcBridA
attribute within HyTime.

6.5.1: Move delims to C.6.3.6 (all-architecture common attributes),
which is where notation and notnames are.

6.5.2 lexmodel: attribute should be \"lexical model element type Gis
(lextypgi).

6.5.2.1 lexmodel: requires support of \"lextype\" option.

6.5.3: Allow location source for location address elements to be
omitted, in which case the location source is the element that refers to
the location address.

6.5.3: Consider separate attributes (or keyword) for GI and model forms
of reftype. (also for conloc).

6.5.3: Make bitskip bulletproof.

6.5.5: Add new attribute: "defatts", attributes in the default value
list whose values are to become the new default if specified for
elements within the scope of the active default value list. In this
case, "specified" also means specified for a selfdvl.

6.5.5: Add new attribute to dvl-atts, \"selfdvl\", which refers to a
default value list that defines the defaults for the current element.

6.5.5.2 dvlist: change \"attlist\" to \"attspecs\".

6.5.3: consider separate attributes (or keyword) for GI and modelforms
of reftype. (also for conloc)

6.6 Add \"inbos\" common data attribute.

6.6 Define SGML as a data content notation with data attributes
depending on value of HyTime attribute, from MIME/SGML:

document: boot

document, subdoc: startup (MIMESGML start-info)

active

6.6 Clarify that an SGML text entity cannot be declared as a data entity
if it is to be parsed in the context of the document in which the entity
declaration occurs (i.e., is to be referenced by a syntactic entity
reference, as opposed to an entity name attribute).

6.7.1 change \"oose\" to \"grove,\" expanded as \"graph representation
of object/property value environments\"

6.7.1 Clarify the handling of properties whose values may be unknown
(unstable, unavailable) at different times during processing.

6.7.1: Add means of specifying the \"provider\" of a property, that is,
the object type (which could be the value of some other property) whose
instances exhibit values of the property. Also, a means of defining
object types and \"atomic\" object types used as simple property values
(= lexical types?).

6.7.4 Modify HyTime property set to be consistent with corrected
architectural forms. \[Note, archforms are automatically object types
and their attributes are properties.\]

6.7.5: Clarify rules for deriving objects from architectures:

Clarify how to define data type (in SDQL sense) for properties derived
from architectural attribute declarations. Have to understand the
connection between lexical type and data type to ensure that the
information is complete. Need a string-to-data type mapping
specification.

Must standardize the primitive datatypes semantically, but not literally
for a particular architecture. SGML property set defines a set of base
data types required by the definition of SGML.\]

1\. Each element type form defined by an architecture is an object type.
Each attribute of an element form is a property of the element form
object. In addition, new object types or properties can be declared.
Object types can also be declared that replace the automatically-defined
object types. By the general rules of object and property precedence,
new properties can be defined that will replace automatically-defined
properties.

For non-architecural elements that use architecture common attributes,
the element type form object has the reserved name \"#COMMON\".

2\. For each architecture you have a property for each element whose
value is the object corresponding to the element type form to which the
element claims to conform. The reserved element type object name
\"#COMMON\" represents the common attributes used for non-architectural
elements.

Names follow the concrete syntax of the name space in which they are
used. An attribute value in the derived architecture or document must
satisfy the syntax of the base architecture as well as the derived
architecture or DTD.

## Clause 7

7.4.1.2: define formal properties of a dimension for first, last, and
qcnt.

## Clause 8

Correct the uncertainty as to context when incorporating a document
fragment (\"partial document\") by means of a location address or other
HyTime facility by defining \"fragment\" and \"fragment context\"
architectural forms. (See FRAGXMP.TXT.)

8.2.1: provide a means of saying \"the locsrc is the element referencing
this one\". This would allow a treeloc, for example, to address an
object in the referencing element\'s content.

8.1 N174: Clarify when address resolution is required.

8.1.2: delete last para and move its sense to start of 8.2.2.

8.1.3: Add note: Although a grove represents parsed data, for example an
SGML document, there is no requirement that the data must be completely
parsed and the grove completely instantiated prior to processing. For
this reason although all objects and properties within the grove can
validly be addressed from the document in which the grove appears, not
all properties or objects will necessarily be available at all times
during processing.

8.2.1: Say that initial locsrc must be an oose, or it is the default
oose for the doc or subdoc in which the element using the initial locsrc
occurs.

8.2.2: Reorder and edit last 2 paras to clarify that an agglink can be
treated as a hyperlink only while it is being accessed as an anchor of a
real hyperlink element.

8.2.4 add \"inverse\" att to nameloc, dataloc, listloc, pathloc: it
selects all of the objects in the location source except the selected
objects.

8.3: Delete last para and move its sense to 8.1.3.

8.3.1: Clarify that the address of an object cannot be resolved unless
the addressed object is an grove.

8.3.1 last para: An ID is invalid unless its element is in the oose.

8.3.2: Generalize for any named object in the oose.

8.3.2.2 Nmlist: add attribute to say overrun handling, as for proploc.

8.3.2.2 Nmlist: Move docorsub and dtdorlpd to 8.1.3 and add locsrc.
Generalize name type to work with any location source (not just the
whole document as at present) and drop \"unified\" as it is handled on
HyDoc. Default is \"sole name space of locsrc\". Nametype is actually
name space type; if list is #ALL it refers to all names in the name
space. (Document element and entity are referenced through the oose.)

8.4.1 dataloc: Distinguish true char from str (which is really bit
combination).

8.4.1 Provide for user-defined token quanta (filter or full HyLex or:
When keyword \"delims\" is specified, value of new \"delims\" attribute
is the set of characters that (in addition to white space) delimit
tokens. When keyword \"alphabet\" is specified, value of new
\"alphabet\" attribute is the set of characters allowed in tokens. (Does
ASCP handle all of this?)

8.4.1 For strings like \"Linda\'s\" with \"word\" quantum, \"s\" becomes
a word. A stop list is needed to prevent that. Tokens in the new
\"stoplist\" attribute would be treated as a SPACE (prior to
normalization). Do we need a separate list for each quantum type?

8.4.1 catsrce and catres: add additional keywords (catsrcsp and
catressp) to indicate when a SPACE character is inserted at each
concatenation point.

8.4.2: Remove confusion of tree and forest.

8.4.2.1, last para: In defining a parsing context, if there are location
address elements that locate portions of data (such as a spanloc), what
happens if \"char\" is not a chosen object type? Is it an error, or does
the parser (as suggested here), automatically include in the oose any
object types needed by a location address (as the text suggests). If the
latter, does the oose only include the needed characters, or does it go
to the character level everywhere? Or do we \"round off\" to the nearest
node of the ooze that includes the location?

If a nameloc or coordinate location address locates an element or data
in an external document, must an oose be defined for that document? What
about proploc? (I don\'t think notloc and bibloc apply to ooses.) (See
also 8.3.1).

8.4.2.2: Provide formal propdefs for these object types.

8.4.2.2 dataobj: in definition, change \"an entity\" to \"a data
entity\". (I think dataobj disappears now that parsing context and oose
have been formalized, as it becomes just another node in the oose.)

8.4.2.2: say that data entities are unabsorbed (external, internal
sdata).

8.4.2.2: say that pseudoelement corresponds to #pcdata token, and that
preceding \"other content\" is not part of it.

8.4.2.2: Move this clause to new 8.1.3.1 and replace with a brief
reference to new clause (to preserve clause numbering).

8.4.2.7 relloc: Add \"preceding\" and \"following\" to possible
relations. Specify that \"preceding\" and \"following\" mean with
respect to a left-list preorder traversal of the tree.

8.4.2.7 Clarify distinction between tree, document, and oose; in
particular, \"document root\" and \"document position\" refer to an
oose.

8.4.2.7 document position: There are two document position properties,
for pathloc and treeloc. The marker list contains positive markers only.
Move position discussion to 8.1.3.1.

Add 8.4.2.8 OOSE location address: like treeloc, but addressed by an
\"ooselist\" \-- a \"crooked path\" through the trees of the oose from
the ooseroot to the subject node. The ooselist is represented as
\"(marklist\|namepos)\*\", where the signed non-zero integers describe a
treepos that locates a node that is the owner of a name space property
in whose value the location source of the next tree in the path occurs.
The latter node is located by the \"namepos\", which is a parenthesized
name pair consisting of a name space property name and an object-id in
that name space.

Example: \"1 3 2 (attributes sources) 1 2\" describes the second token
in the value of the \"sources\" attribute of the second child of the
third child of the ooseroot.

8.5.1 notprop: \"empty\" requires qualified object type name. Default
changed from \"ignore\" to \"error\" for safety.

In 8.5.2, Add a note: The notation locations used as a notation source
should have a similar query context as the the original notation
location, but of course a HyTime engine cannot enforce this requirement.

8.6: say that the top rung of a location ladder must be an explicit or
(possibly) implied oose.

8.8: add single location source restriction.

## Clause 9

9.2.1: Change \"endterms\" to \"anchdesc\" and \"link end term\" to
\"anchor descrpition\". Change \"linkend(s)\" to \"ancadd(s)\".

9.2.1: Replace intra and extra with single attribute \"traverse\" that
takes the following values, one for all anchors or one for each anchor:

Traveral options (all except \"E\" relating to internal arrival
following traversal from one anchor of the link to another):

\"E\" traversal is possible following external arrival

\"I\" traversal is possible following traversal

\"D\" departure from link (what was \"E\"). (Departure applies only
following traversal)

\"A\" means all forms of movement are possible from the anchor (e.g.,
D(E or I)R).

\"R\" means you can only return to the anchor from which you traversed
to this anchor.

\"DR\" Departure or return.

\"DI\" Departure or traversal.

\"N\" No further movement is possible from the anchor following
traversal to it.

\"P\" Traversal to this anchor is prohibited.

NOTE: It is not meaningful to restrict access to an anchor from outside
of it based purely on its status as an anchor of hyperlink (but access
may be restricted for other, application-specific reasons, such as
security level).

Default is \"A\".

9.1.4 Clarify that \"scrolling\" a document is not traversal of a
hyperlink. It is a way to access an object that is an anchor without
traversing a hyperlink. When an anchor is accessed by scrolling, the
\"extra\" rules apply to subsequent traversal. When an anchor is
accessed by traversal, the \"intra\" rules apply.

9.1.4 , page 72 para 4: clarify correspondent links.

9.2.1 linkends: clarify that one can be omitted, in which case the ilink
is the first anchor (for clink compatibility).

9.2.1 ilink: Clarify reftype constraint comment.

9.2.2 clink: Clarify reftype constraint comment.

9.3 (NEW): A \"notation-specific contextual link\" (NOTCLINK) element
type form is needed for retro-fitting some existing applications to
HyTime. It would be like CLINK, except that the location of the REFSUB
anchor would be specified in a data content notation, rather than as an
IDREF. An optional ENTITY attribute is provided; text will emphasize
that it is easier to manage system dependencies (like file ids) if they
are in the prolog, not in the attributes. (Refer to Annex C.3.6 for new
method of identifying data attributes that are used as element
attributes, and avoiding name conflicts. It allows the notation
processor to look at attributes and/or the content to locate the REFSUB
anchor.) Perhaps include example of HTML \"A\" element type. Mention use
of notnames and HyNames to control where notation data is specified;
e.g., to put linkend in syntactic content: HyNames \-- User names for
architecture attributes \--

CDATA #FIXED \"linkend #CONTENT\"

To put linkend in href attribute and make it subject to the notation:

HyNames \-- User names for architecture attributes \--

CDATA #FIXED \"linkend href\"

notnames \-- User names for notation data attributes \--

CDATA #FIXED \"#NOTCONT href\"

NOTE: It is not an RHE for a notclink-form element instance to fail to
specify an anchadd or entity value. \[This allows modeling of HTML A
when it functions as an addressing target and not as a clink and avoids
the need to explicity unset the HyTime attribute value.\]

## Clause 10

10.2 fcs: multiple FCS elements of same element type describe different
spaces unless they have the same \"fcsname\" attribute (which requires
the \"splitfcs\" option).

fcsname \-- Name of semantic FCS described by the element \--

NAME #IMPLIED \-- Default: FCS is unnamed \--

10.2: Define \"effective extent\" property of an fcs for first and last
quantum on each axis that is occupied by an event, represented as an
extent. Clarify that multiple instances of an fcs can have a different
effective extent (i.e., no need to change the axisdim for each instance;
just choose one axisdim whose magnitude is convenient for all
instances). In other words, the fcs is like a grid (or graph paper) of a
useful size; the things you position on it don\'t have to cover it all.
The axisdim is useful, however, to provide convenient axis markers and
for fcsloc.

10.4.1: It is an RHE if the specified grpscope does not equal the
calculated actual group scope.

10.5.3: Accend: change \"accend\" to \"accobj\", permitted values are
\"anchdesc\" or \"anchor\".

10.5.3 Remove \"clink\" from reftype list of acclink.

10.8: Eliminate fixed IDREF attribute (and other bugs) by inserting
after Note 309 a new heading: 10.8.1 Calendar attributes. Move the
contents of 10.8.1.1 and 10.8.1.2 (without headings) to end of new
10.8.1 and replace formal specification. (See pecat3.txt.)

10.8.1 calspec: Renumber as 10.8.2 and eliminate content model ambiguity
by replacing formal text. (See pecat3.txt.)

10.8.2 Dimension references to calendars: renumber as 10.8.3

## Clause 12

Change all declarations to new syntax and refer to them by the correct
names.

## Annex A

General: Consider moving element type and notation definitions, such as
HyLex, HyPD, etc., into the body of the standard, at the point where
their base architectural forms are defined. Use Annex A only for large
groups of instances (property sets, granule definitions).

A.1 Clarify the relationship of data types, value types, properties, and
data content notations, with respect to their use in HyLex models and
propdef values.

A.2 Revise property sets to use new obdef/propdef/typedef forms. Sets
should include all properties in SGML, HyTime, and SDQL standards.
Definitions and lexical models should be explicit. (Note: SGML property
sets will be normative in the DSSSL standard.)

A.2.1.2.1 add: pn=dsentref dspec=character (bit combination?)\>data or
SUBDOC entity reference. Value is entity name of \"character\" that is a
data or SUBDOC entity reference.

A.3: Delete HyQ and replace with equivalent based on SDQL.

A.4: Delete HyOp. Replace HyFunk with equivalent based on the DSSSL core
expression language (DSSSLexp).

## Annex B

Remove references to SGML Users\' Group and say which publications
and/or Internet sites have the material.

## Annex C

General: Double check use of %ArcCFC; in content models.

Clarify that for any non-manditory attribute, there must be a default
value defined in the architecture. In other words, the default behavior
has to be defined in the architecture. The default values apply even if
the facility is not supported. (Make sure HyTime does this.)

C.2.3.2 Clarify conformance to att val prescription in meta-DTD (both
DTD and meta-DTD must be satisfied. (SGML att value is passed to arch
engine as input to its attval checking.) Discuss conflict of concrete
syntaxes (e.g., better to use CDATA in DTD and NAME in lextype; check HT
for consistency in this regard). Specify when a name applies to the
architecture and when it applies to the instance.

Recommend that concrete syntax ofarchitecture be designed for use with
all expected derivatives; i.e., the broader the potential use, the
closer to the RCS (or the usual concrete syntax of the expected user
community) it should be (particularly the name spelling rules).

Consider new option for ArcBrid that turns off architectural common
attribute processing except ArcBrid.

C.3.5 Clarify that the ArcName attribute for the ArcDoc element is
omissible if there are no required architectural attributes. This
supports promoting a non-architectural element that contains
architectural element to the status of document element.

Attributes that are properties of documents should be declared as
support attributes of the architecture notation.

There is no reason to prevent the specification of support attributes
independently for subdocuments as there is no added support implications
by the use of subdocuments with different support declarations.

C.3 Clarify that #PCDATA content is passed to the architectural
processor if and only if the meta content model allows PCDATA. When the
meta content model does not allow PCDATA, then any data mixed with
architectural elements is not considered for architectural validation.
The PCDATA content of non-architectural subelements is never considered
by the architectural processor.

## Annex D

General: Split off system identifiers into an informative annex.

General: The notations used to define storage managers are declared in a
separate document that serves as a system-wide definition of the storage
managers provided on that system. These notations are not declared in
the documents that use these storage managers. The FSISM processing
instruction optionally names the document that contains the storage
manager declarations, which can optionally name a entity declared in the
document. It can optionally redeclare the delimiters used for the FSIs
used in the document. If the FSISM processing instruction is omitted,
the default storage manager definitions are used, however those may be
defined.

D.1.1 Allow optional end-tags so that a future SOS may include another
SOS in its content.

D.1.1 Clarify to what the extent for ThisOne storage manager is
relative.

D.1.1 Consider renaming ThisOne to ThisEntity, to distinguish from

ThisStorageObject.

D.1.1 Add \"ThisStorageObject\" storage manager (allows distinction
between entities and storage objects when a single storage
objectcontains multiple entities).

D.1.1. Consider Comments in UK-ANXD.TXT.