NOTICE OF INTELLECTUAL PROPERTY RIGHTS
This document and its attachments are being developed as a Corrigendum
to an International Standard. When published, the material will bear
a copyright notice of the International Standards Organization. Until
then it bears a copyright notice of its author, as follows:
(C) Copyright 1995 Charles F. Goldfarb. This document may be copied
and distributed freely for the limited non-commercial purpose of
participating in the development of International Standards provided
that the document, including this notice, is not modified in any way.
NOTICE REGARDING STATE OF THIS DOCUMENT
This document is being distributed for ballot in electronic form, as
provided by the new JTC1 directives. Accordingly, changes required for
appropriate presentation in printed form will be made by the Working
Group prior to publication. Said changes will include removal of the
above Notice of Intellectual Property Rights and this Notice.
The files hi1anarc.txt and hi1anfsi.txt are part of this document.
TECHNICAL CORRIGENDUM 1 TO ISO/IEC 10744
Draft for ballot: March 27, 1995
This Technical Corrigendum is being published to provide corrections
for errors and ambiguities, as follows:
1. Corrections for errors and ambiguities discovered during early use
of the standard, many previously distributed informally in the
"Catalog of HyTime Architectural Forms" referenced in Annex B of the
standard.
NOTE: A corrected "Catalog of HyTime Architectural Forms" will be
made available upon publication of the Corrigendum.
2. Corrections of misalignments in terminology and concepts between
HyTime and SGML and its related standards. In particular, ambiguous
use of the term "parsing context" has been corrected to distinguish
the "originating object structure environment" (oose) produced by
parsing, from the parsing context itself. Nameloc, notloc, and relloc
have been changed to reflect this distinction and provision has been
made in property sets to define the object types to which the
properties apply.
3. Corrections of errors resulting from the confusion of general
requirements for architectural form definition with their specific
application to HyTime, largely accomplished by collecting the general
requirements in a new normative Annex C and removing them from the
body of the standard.
4. Correction of a flaw in the sbento design that prevents SGML text
entities from being parsed normally by SGML parsers, accomplished by
making insbento a "storage manager" substring attribute that occurs in
the system identifier, rather than a data attribute that can only be
used with data entities. The general requirements for identifying
storage managers so that they do not impact conventional system
identifiers are presented in a new normative Annex D, to avoid
confusion with HyTime data attributes.
5. Correction of the uncertainty as to context when incorporating a
document fragment ("partial document") by means of a location address
or other HyTime facility, accomplished by defining "fragment" and
"fragment context" architectural forms.
-------------------------
GLOBAL CHANGES TO FORMAL DEFINITIONS
%HyBrid is changed to %ArcCFC.
"-- (name) attributes --" is now "-- Attributes: (name) --".
Unnecessary s+ and s* removed from lextype models.
Entity declarations in mDTD are meta so The attribute list form
The any-dcn attributes can be defined for any notation, provided that the attribute "HyBrid" is also defined so that the notation can be recognized as having HyTime attributes.
The HyTime data attributes require support of the "dcnatts" option.
6.6.2 altreps: change "using different data content notations" to
"possibly using different data content notations".
6.6.2 Delete HyNames from attribute list and its description from the
text.
6.7 1st para: change "object" to "object types and their"
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 (new): Property Sets and Architectures
Every element conforming to an element type architectural form
exhibits the property "arcform". Its value is an object that exhibits a
"defining architecture" property as well as other properties defined
by the attributes of that form. (Therefore, we may not need special
object types for link, loc, and fcs in order to examine their
properties, and we could eliminate the "joint" attribute from
proploc.)
Elements with common attributes exhibit the "attform" property. Its
value is a set of objects with the same names as architecture names,
and with properties corresponding to the common attributes of that
architecture that were defined for the element. The attform value
"all-arc" is used for the common attributes of all architectures
(defined in Annex C).
Clause 7
7.1.1 Note 142: change "qcnt" to "quantum count".
7.3.1 after N152 add: A granule name cannot be the same as another
granule name in the same measurement domain.
7.3.1 Add to gn in granule: -- Constraint: unique in measurement domain --
7.3.3: Add to basegran in schdmeas: -- Constraint: must be granule names --
7.4.1.2 elemref: add "calspec" to reftype group.
7.4.1.2: define formal properties of a dimension for first, last, and
qcnt.
7.4.2.3 para before N171: change "document" to "document instance".
Clause 8
8.1 N174: Clarify when address resolution is required.
8.1.2: delete last para and move its sense to 8.1.3.
8.1.3 (new) Parsing Context:
A parsing context (which is defined by a notation, plus object-types
to be recognized in applicable property sets) is distinct from the
originating object structure environment (oose) created by the parse.
The nodes of the oose are the objects of the specified types, less any
pruned by a specified dimlist. Every object therefore has its origin
in the oose (pronounced "ooze"), either as a node in the tree
descending from the root, or as a node in a tree that is the value of
a property of an oose node (recursively).
The source object that is parsed to create an oose can be in any
notation, of course including SGML. The oose is informally referred
to as a "(notation-name) oose" (e.g., SGML oose). It is an error if a
source object is not parseable by the specified notation, although an
implementation may not be able to report the error.
The value of a property exhibited by an oose node could be in the form
of a set of named objects (for example, an SGML element could exhibit
an attribute list). The set of names of such objects is known as a
"name space". Objects identified by names in a name space can be
addressed using a nameloc element.
In addition to their normal properties, objects that are oose nodes
also exhibit properties that identify the oose, the root node of the
oose, the subject node's position in the oose, and the node's
"origin". The origin of a node is its parent if it has one, otherwise
the node exhibiting the property of which the subject node is a value.
An application can specify the defaults for an oose element type, and
a default oose element type if there is more than one. If an
application fails to do so, the default oose for a given source object
is the default oose for an SGML parsing context (see below).
8.1.3.1 SGML parsing context
Data nodes in an SGML oose can be individual characters, token quanta
of the types allowed by dataloc, and/or pseudo-elements. Characters
are children of token quanta, which are children of pelements, which
are children of elements. However, any levels of the data hierarchy
can be omitted simply by not including them in the nodetype
specification.
Elements in an oose exhibit a property that indicates whether they are
inclusions or proper subelements.
An ID reference from an object in an SGML oose is invalid unless the
element that exhibits the ID occurs in the same oose as the reference.
(However, the element could be a location address whose object occurs
outside of the referencing oose.)
If not otherwise defined by an application, the default oose in an
SGML parsing context is that produced using the default property set
names (qpnpsn), the node types element, pelement, dataobj, and
dataent, and an empty dimlist (i.e., all nodes of the specified types
are included).
It is an error if the source object in an SGML parsing context
is other than an SGML document entity or SGML subdocument entity.
8.1.3.2 Non-SGML parsing contexts
When the notsrc option is supported, an oose can be created with a
notation other than SGML. The object types and properties must be
defined for the notation, which requires the xpropdef option.
There is no default non-SGML oose.
8.2.1 locsrc: default value changed to "#CURRENT".
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.4 (new) add "inverse" att to nameloc, dataloc, listloc, pathloc:
it selects all but the selected objects.
8.3: Delete last para and move its sense to 8.1.3.
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.1 Nameloc: add attribute to say overrun handling, as for
proploc.
8.3.2.2 Docorsub: default is doc or subdoc in which nmlist occurs.
8.3.2.2 Dtdorlpd: default is base DTD.
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 empty it refers to all names in the name
space. (Document element and entity are referenced through the oose.)
8.3.2.2 obnames: default value changed to "nobnames".
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.
8.4.1 definition of NORM: change "RE" to "RE, SPACE"
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 Add to 4th para: During concatenation, data content of elements
that occur in element content is separated from the data content of
siblings by a SPACE character.
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.2: Provide formal propdefs for these object types.
8.4.2.2 dataobj: in definition, change "an entity" to "a data
entity".
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.
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.
Generalize position representation to include proplocs, as in a
location ladder (e.g., for position of attribute values).
8.5.2: Delete 1st para after N220 and change following para to "A
notation-specific location address cannot be a location source. It
can be a query domain only for other notloc elements (which should
have the same query context)."
8.5.2 notloc: in comment, change "address" to "HyTime address".
8.5.2 Delete multloc attributes conventional comment.
8.6: say that the top rung of a location ladder must be an explicit or
implied oose.
8.8: add single location source restriction.
8.8: delete references to coordloc; it is now mandatory.
8.8: change notsrc description to: data in a notation other than
SGML can be the source of an oose (requires: xpropdef).
Clause 9
9.1 N243 item c): change "hyperlinks" to "IDREFs".
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.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: Say that one anchor is the CLINK itself (not the content of the
CLINK, as at present). I.e., replace 1st 2 paras with:
The element type form
The link type of a contextual link expresses the type of reference.
There are two anchor roles: the "reference mark" (named "REFMARK"),
which is the link element, and the "reference subject"
(named "REFSUB"),
which is identified by the attribute