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 any-dcn consists of common data attributes that provide data for modification integrity checking, specify alternative representations of an entity, and specify other information that an application can use to interpret and access the data of the entity. These attributes can be used individually in attribute list definitions; each is considered a separate facility from the standpoint of determining whether it is mandatory or non-mandatory.

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 contextual link (clink) allows a reference to a location to be made in context; that is, one anchor of the link is the link element itself. In an interactive application, the self anchor can be accessed externally from an adjacent element or data in the document hierarchy.

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 link end (linkend). The reference subject can be an aggregate. 9.2.2 clink: Clarify reftype constraint comment. 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). 10.3 axisord: omitted axis name means all events occupy full dimension. 10.7 impfcs: type of imposed FCS; change "IDREF" to "NAME". 10.8.1 calspec: respecify content model to remove ambiguity. Annex A A.1.2 Clarify that s* can occur between and around tokens, even if not in model. A.1.3 arg: balance parentheses. A.1.3 ATTORCON: balance parentheses. A.1.3 qpn: balance parentheses. A.1.3 Correct discrepancy between the syntax of the spec element type form (6.7.2) and the syntax for the corresponding hylex construct (A.1.3); the content model for spec allows (qpn|qltn)+ whereas the hylex model only allows one qpn or qltn per specifier. A.2 HyPD qltnlmgi: "gil" changed to "GIL". A.2.1.2: Define PTR 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.2.1.2.1 NAME needs definition: pn=NAME>name A.2.1.2.1 NUMBER needs definition: pn=NUMBER>number A.2.1.2.2 docpos: clarify as "pathloc document position" A.2.1.2.2 Add docpostl: treeloc document position A.2.1.2.3 KEYWORD: add "psn=HTsem3"; add definition "keyword parameter of an SGML markup declaration". A.2.1.2.3 tag: add "psn=HTsem3". A.3.1 HyQ: Add after 4th para: Query args, operands, and other nl nodes are evaluated as they are ordered (left to right), and before the query (or operator or other nl) is evaluated. A.3.2 @lc: definition changed to "Value of attribute defined elsewhere" A.3.2 Delete informal heading "-- HyQ --" and number others A.3.2.1-9. (The corrigenda to A.3.2, below, use the new numbering.) A.3.2.1 dquery, iquery: allow qdomain without args. A.3.2.1 qdomain: correct second comment is "Qdomain must be specified if the first arg is nl or oo." A.3.2.1 args: should allow nl as well as nodes. A.3.2.4 union: clarify description of result nl to "Result nl contains nodes that occur in at least one operand nl." A.3.2.4 inter: clarify description of result nl to "Result nl contains nodes that occur in every operand nl." A.3.2.4 diff: eliminate ambiguity between diff and symmetric diff by adding: sdiff -- Symmetric difference of node lists (non-common membership) -- -- Result nl contains nodes that occur in only one operand nl. -- 'Diff('nl+')' A.3.2.5 hitloc; allow explicit keyword: (('Hitloc('match')' ) | match) A.3.2.6 hylex: balance single quotes. A.3.2.7 exists; allow explicit keyword: ('Exists(' (nl|match) ')' ) | nl | match) A.3.2.7 Forall: clarify that argument query applies to each nl node in order. A.3.2.7 Forall: clarify that empty node list returns TRUE; i.e., forall(). A.3.2.8 Compare: delete comma after "@quantum?". A.3.2.8 ordered: clarify that overlap refers to position. A.3.3 HyQ qltnlmgi: "gil" changed to "GIL". A.3, A.4: Fix HyQ, HyFunk, and HyOp so that they can be used together as a single expression language. Add dimref and nameloc as operators. A.5.2.4 change "millenium" to "millennium". A.5.2.5 Chain: change "feet" to "foot". Annex B Remove references to SGML Users' Group and say which publications and/or Internet sites have the material. Annex C Add text in file hi1anarc.txt as new normative Annex C and apply following corrections to it. 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). Say that ArcCopy can apply to individual atts (or just individual common atts?) Say that common att names must be unique among all att names in architecture. Explain conventions for distinguishing Arc facilities provided by annex C from those provided by individual architectures. Use different spelling conventions for declarations and object names (e.g., Arc????). Say the conventions for names in arch form declarations (distinguish declaration names, like ATTLIST, from objects declared, like HyDoc). The omitted tag minimization parameter in a meta-DTD is advisory only, for possible use when an element type is identical to the architectural form. Clarify that a base architecture can be imputed to a DTD by means of a processing LINK. The architecture notation and its attlist are declared in the DTD, but the meta-DTD entity can be declared in the LPD. Annex D Add text in file hi1anfsi.txt as new normative Annex D. Say that sbento is an archive notation for storage management, rather than an ordinary data content notation. Put general rules for declaring storage managers ("formal system identifier") in new normative Annex D and refer to them.