[Mirrored from: http://cs-www.bu.edu/students/grads/dgd/HTTC.html]
This document contains a number of types of comment, some based on the proposed changes that are only available to ISO or ISO national body members. This is also a document in flux. The current version was last updated on June 8, 1995.
David Durand has made some additional suggestions (6/28) that provide an interesting alternative to the Annex C comments in this document.
The concerns addressed by this document fall into the following three groups:
The last two of these issues are relatively straightforward, but the first is probably the most controversial and important, in terms of what to do with the TC proposal in hand.
Annex C, as it stands, addresses two problems. The first is a thoroughgoing revision of the explanation of architectural forms as used in the standard. This revision improves the organization of the document and should help to increase understanding of architectural forms, and the HyTime standard itself in the community. We heartily approve of these changes. The second problem addressed by the annex is the standardization of the notion of architectural form, as evinced, for instance, by the language suggested in the annex: "A document architecture conforming to the architectural form definition requirements of international standard ISO/IEC 10744."
This second level of standardization is premature. While the notion of architectural forms is becoming popular in the SGML community, there is not yet a wide body of experience with applying it, nor is there wide agreement as to how they should be applied or what syntax is appropriate for defining them. HyTime originated the notion of architectural forms, and is the first application of this notion to markup specification; it is premature to standardize the syntax and semantics used in the HyTime definition for such a complex set of problems without a proper review. In essence, as worded, Annex C is a smaller standard embedded in the HyTime standard, and as a second standard it is premature.
We feel that the notion of a standard mechanism for architectural forms is an important one. In fact, it is much too important for it to be done based only on the relatively limited examination and analysis possible during the technical review process. Architectural forms should not be standardized hastily, and the language of the proposed Annex C should be revised to eliminate any implication that it is an independently applicable standard.
We do feel that an architectural form language standardization project should be started within WG8. Given the rapidly growing level of experience, and the probable usefulness and demand for such a standard, it seems a good candidate for fast-tracking.
The problem here is a matter of HyTime support for one of the most common existing idioms for the expression of hypertext links: an attribute value describing the location of a link destination. This form of linking is required for HyTime to be compatible with the existing practice in the HTML and TEI communities and these changes will make the process of converting existing HTML or TEI documents to HyTime as painless as possible.
While anyone fully conversant with SGML will realize the serious shortcomings of HTML as a markup language, the interests of HyTime and the larger community will be best served by making the transition from old to new data formats as easy and painless as possible.
We also observe that if backward compatibility were the only issue involved, then this might not be worth changing, though HTML incompatibility will certainly not help HyTime's wider acceptance. However, fact this form of reference, while less composable than HyTime's built-in mechanisms (with their full spearation of location and linking), are often more convenient for use when creating the most common types of simple link.
As this was a major
point in the the original TEI comments on HyTime, which both we and the
editors erroneously believed was handled in the standard, a resolution of
this issue is critical. It is not strictly correct to say that there is no
way to accomplish this method of reference in Hytime, as we have found a
way to do it with use of the aggloc=agglink feature. The
interpretation on which this technique is based, while we believe it to
be fully justified by the text, may be
based on an original unclear expression of the editorial intent of the
standard.
The issue of intent and interpretation, however, is not critically
important. We chose this interpretation as the best way to accomodate a
mandatory need for our communitites while remaining within the letter of
the standard, and we propose several changes to this feature and some
others in order to clarify this usage, and to extend it in generality. The
use of aggloc=agglink is neither elegant nor obvious.
Another and better solution exists. Currently the only application of
aggloc=agglink that we are aware of (other than our own) is
for representing menus. We feel that in fact the entire notion of
agglink is an unattractive combination of the location and
linking functions of HyTime that does not satisfy any needs elegantly.
The best solution to the problem of aggloc=agglink is to
eliminate it, and accomodate its unique applications with the more general
facilities already presetn in HyTime..
The menu application can be easily handled without using
agglink. A menu of 10 items represented as an
multloc with 10 members and aggloc=agglink could
be better represented as an ilink with 10 linkends, if our suggestion to
make ilink capable of having a variable number of linkends is taken. This
is a simple matter of making it possible to have a non #FIXED
anchrole attribute on the ilink form.
We have also worked out a solution to our problem that is superior to
aggloc=agglink solution. This is to create a new
architectural form notlink that would be identical in
attributes, content model, and semantics to ilink with the following
exception. It would not have a linkends attribute, and, like
notloc, its notation attribute would indicate an
application convention for determining the effective linkends. This would
enable “short-form links” to use all the facilities of an ilink. It would
also provide all the capabilities of clink as well, since the notation
could, if desired, define the element itself as one of the linkends.
This scenario is the really a best case. A critical need
can be met by extending ilink, and a point of confusion (i.e. the agglink
feature) can be removed.
We have organized our comments in 2 sections: one devoted to ambiguities and omissions that we have found in our work with the standard, but which are not resolved in the draft document we have seen, and the other devoted to changes and improvements that can be made without seriously disrupting current practice.
This section is organized by particular problems we have found in the definition of HyTime. All of these are cases where the standard either implies a distinction which cannot be made, proposes ambiguous rules, proposes rules that are not self-consistent, or requires editorial amendment for clarity or accuracy.
There are several severe problems with traversal rules. In particular, the standard as written is under-determined -- there are cases where the current rules do not allow an application to determine if traversal is allowed or not. First we discuss the problems, and then propose a simplification that is unambiguous, and powerful. Following the description of the new rules, we give a worked example of specific traversal rules that can be created with the new system. This extended discussion would not be required in the standard, as it can be deduced from the defining rules of the proposal.
We have not yet phrased this proposal in terms of specific changes to the standard, but have instead offered a self-contained explanation of the new rules. The next step would be to figure out what to delete, and where to insert the new text.
First, a description of the problem with the existing system:
External and internal traversal rules apply depending on how an anchor was reached. For instance, if there is an anchor "anchor1" that is shared between ilinks "ilink1" and "ilink2", and I arrived at that anchor by traversing ilink1, then I would need to check ilink1's "intra" attribute on any traversal operations.
Now for the problem: since anchor1 is also a linkend of ilink2, I must also check the extra attribute of ilink2, since I didn't access anchor1 via ilink2. It's possible that the traversal rules of ilink1 and ilink2, both of which are relevant, could conflict. Say, for instance, to continue the example, that "ilink1" has intra=N, and "ilink2" has extra=A. In this case link1 says "no further movement is possible", while ilink2 says to go ahead and move if you want. This same conflict could occur if "ilink1" had intra=I as well, as long as external traversal was not allowed.
We propose that this problem can be avoided without significant loss of generality by simplifying the whole traversal system, in the following way.
First, for any attempted traversal, the system only need look at the attributes of the link along which traversal is being attempted. This changes the definition of internal versus external traversal, but both the intra and extra attributes would survive, but with new and simpler meanings. The intra attribute would be used if the anchor had been accessed via traversal along the link being tested, otherwise the extra attribute would be used. With this simpler system, we can also simplify the values of the traversal attributes. The new list of permitted values is:
All of the above values apply only for the type of traversal (internal or external) being attempted from the anchor.
Note that for the extra attribute the values I and B are not allowed, since there is no way that incoming traversal via a link can ever be external traversal along that link. For external traversal the only possible values are O and N, which either permit or prohibit outgoing traversal from an anchor along the link in question.
For internal traversal the value O is disallowed, since outgoing internal traversal is only possible from an anchor when incoming traversal can be performed first (since internal traversal is by definition traversal initiated after arrival along a link).
We get the following combinations of traversal for a link
intra= I B N -------------------------- extra=O | 1 2 3 extra=N | 4 5 6
Note that it's not ambiguous what to do with a shared anchor as the attributes are only checked with regard to a particular link. Also note that for shared anchors, each link's traversal rules are independent of those of other links sharing the anchor. This gives the added advantage that it is harder to accidentally damage the usability of pre-existing links merely by the addition of new ones.
If I want to link an arbitrary number of things together, (a generalized multi-way link) I can use the multloc attribute form with aggloc=agglink, but I cannot specify traversal rules or endterms for the components of the agglink. Even anchroles might be useful (though they could not be fixed if used for such an application). The easy way to fix this is to add the endterms, intra, extra, and possibly the anchroles attributes into the multloc attribute list form. If anchrole is allowed, either the "#FIXED in-dtd" restriction should be removed from it, or less nicely, a new attribute could be defined for "varying anchor roles"
Change confusing wording in the description of aggloc=agglink on page 52 (bottom) Para 6 of clause 8.2.2. It reads:
" ... or that it is an aggregate that can be treated like a hyperlink with established traversal rules (agglink). The traversal rules treat the element itself, the aggregate, as both an ilink element and an anchor, ..."
The terminology "treat like" implies that such an aggregate is not a link, but merely something that "functions as" a link. The purpose of HyTime is to define how certain objects function. Since an agglink functions as a link, it is a link. Change the prose to read:
"that the aggregate is a hyperlink with established traversal rules (agglink). The traversal rules treat the element itself, the aggregate, as both an ilink element and an anchor, ..."
Clause 9.1.4 , page 72 para 4, discusses correspondent traversal. The exact words are: "Some hyperlinks have the property that their anchors are either single locations, or aggregate location links that all have the same number of members". This is grammatically ambiguous, and can be read two ways, either as:
The first disallows some nice linktypes, like a link that has 3 anchors:
The passage also seems to imply that all aggregate anchors must have correspondent traversal if any single aggregate anchor has it. This anchor restriction, if intended, is unnecessary. The language should be rewritten to make clear that only aggregate anchors with correspondent traversal on the same hyperlink must have the same number of members.
We recommend the adoption of interpretation 2, and removing the implication that all aggregate links must be correspondent if any are.
This can be achieved by changing page 74, paragraph two to read:
"Some hyperlinks may have correspondent traversal specified for aggregate anchors. All aggregate anchors of a hyperlink for which correspondent traversal is specified must have the same number of members. The ordering of members in such aggregates is significant. Each member of such an aggregate is considered to correspond to the members of all other aggregates with correspondent traversal that are in the same relative position. Each such member is directly linked to its corresponding members, as well as to the other anchors of the hyperlink."
The standard states that duplicate options are ignored. However, some options, e.g. manyaxes, take parameters. The standard does not say what action should be taken when conflicting values of these parameters are specified, e.g. manyaxes=1 manyaxes=5. It is impossible to "ignore the duplicate", because there is no way to tell which specification to ignore. Conflicting option settings should be an RHE.
No sub-clauses of clause 7 other than 7.1 are enabled unless the scheduling option is specified. Since the 'function' attribute form is defined in clause 7.4.1.3, HyQ macros and other function forms may not be used unless scheduling is turned on. Recommend moving the definition of function into clause 7.1, or optionally adding language to the specification of clause 7's applicability to allow the use of the function attribute form without requiring the use of the scheduling module.
Requiring the scheduling module to as a prerequisite to allow the use of macros in HyQ is an unreasonable dependency.
Correct these to reflect mathematical terminology and fact, or delete them. Examples:
In paragraph one of 10.1, the assertion that "mathematical space" (which is not a well-defined concept in mathematics) is infinite is incorrect. Both finite and infinite geometries and topologies are common in mathematics, one reason that the singular notion of "mathematical space" is not in use. There are many notions of space commonly used in mathematics.
If an informal mathematical definition of HyTime FCS is required, the following could serve:
A HyTime axis is the set of all natural numbers less than or equal to a specified value (its "dimension" in HyTime terminology). A HyTime FCS is the Cartesian product of its axes.
Note 146 in clause 7.2.1 duplicates the language above, and adds an additional mention of the term subspace, which is also not well defined mathematical terminology. Repeat the definition above, or delete the note. A cross-reference to the suggested definition in clause 10.1 might best replace the entire discussion of FCS's and addressing in this section, which overlaps the discussion and definitions there in different words.
In clause 8.4.2.1, Note 201 is confused. In standard mathematical terminology here is no such thing as a tree with multiple roots. There are trees and there are forests. HyTime encodes a forest as a tree with a dummy root node. The text is also rather confusing: The sentence before note 201, "A node list is the therefore the root level of a multiply rooted tree" is nonsensical. There is no such thing as a multiply rooted tree.
The whole discussion from para two through the paragraph preceding note 201 should be replaced by:
HyTime defines a node list as a sequence of nodes.
Note 200 -- In an SGML parsing context, each node could be an element of a document, so that the node list would correspond to a forest of element tree structures.
A HyTime node list may be addressed as a sequence, or as a tree depending on the addressing form used to address it. When a HyTime node list is addressed as a tree, or used as a node, it is treated as a single tree with a dummy root node, whose children are the members of the node list.
Note 201 -- HyTime thus does not directly represent the mathematical concept of a forest, except as a sequence (list) of trees
It is also possible to turn a tree node, or a node list treated as a tree, into an "expanded node list", containing all the nodes in the order they would be visited in a pre-order traversal of the tree"
Propdef and the Useful property sets of A.2.1 are much less useful than they should be because a propdef does not specify the form of the result of querying a property. In the case of some of the properties (like the SGML delimiters), the form is pretty clearly implied, but the form of some of the semantic properties is much less clear. We suggest that the propdef forms even for the inherent properties be given lexical models with the 'lex' attribute. This will allow the properties to be used in HyQ queries or as locsrc for dataloc in an implementation independent manner.
Also, clarify that proplocs for inherent properties must specify a locsrc which has an associated parsing context from which the values will be obtained.
The following notes discuss improvements to HyTime, rather than faults that require correction. Some of these point to missed generalities, while others identify features that are widely requested that cannot be handled with the current system. In a few cases, we also identify places where the current definition, while well-formed, is inconvenient or inadequate.
The requirement that anchrole be a "#FIXED in-dtd" element is overly restrictive. Many hypertext systems provide n-ary links, or links with anchor-roles that can vary by link instance. (Xerox PARC's Aquanet, is one recent example). Removing this restriction would enable representation of n-ary links with named anchroles. Alternatively, a new option, "manyroles" or "varyroles" could enable non #FIXED anchroles.
An FCS represents a discrete virtual addressing scheme that will usually be translated, at presentation time, to a presentation-dependent device coordinate space (that may or may not be discrete, and, if discrete, may have a different resolution).
A new extent form to represent polygonal regions would be a very useful addition to HyTime, and would enable intelligent resolution translation. Currently, to represent non-rectangular areas with a HyTime FCS, one must scan-convert the region to be represented at the resolution of the FCS, and construct an aggloc representing the coordinates in terms of that conversion. If the presentation medium has a radically different resolution, the result will have many artifacts (jaggies) that will not reflect any reality other than the differing resolutions. This is a rare case where HyTime's FCS mechanism forces one into resolution dependence rather than serving its proper function of allowing documents to be isolated from such details wherever it is sensible.
In general this is a bad approach, particularly for graphics, since the HyTime specification will essentially encode information at a particular resolution, at the cost of being hard to use at other resolutions. Good scaling between different discrete spaces is an unsolved problem in computer graphics. For an idea of how bad the results generally are, look at scaled bitmap fonts on a Macintosh.
This is a hidden device dependency in the current definition for the representation of non-rectangular regions in an FCS.
Handling polygonal extents would require the introduction of two new
architectural forms:
point -- represents a point in an FCS.
polyext -- represents parts of an FCS enclosed by a boundary.
The following text preliminary architectural form definition and text are suggested:
Note ??? -- the definition in terms of "crossings" serves to identify the contents of a normal non-self intersecting path. This definition provides an easy to implement method of handling self-intersecting paths. This is the standard definition of "self-intersecting polygon" already used by most computer graphics systems.
The "point" architectural form could also be used in the definition of user-defined entities such as spline curves, circular arcs, projection to motion paths, and the like. While none of these are ready for standardization, almost all geometric information can be specified as points subjected to some function (that could be represented by an element type, or AF) that defines a region or object.
For all forms in clause 8, make id #IMPLIED.
This enables locators that are also links (with aggloc=agglink) to be used without requiring an ID attribute that is not needed. This makes handling HTML legacy documents much easier, and imposes no incompatibility with existing HyTime document instances. Because of the interaction with HTML we think that this is a particularly important extension. Note that when aggloc=agglink is not being used, the id is effectively required if the location element is to serve any purpose. This de facto requirement renders the syntactic constraint redundant.
Change definition of HyNames. cf. MHW, p284.
The #CONTENT value of an attribute can be used to move that attribute's value into the content of an element, but there is no way to indicate that the inverse transformation of content into an attribute value be performed. Add a way to specify that the "normal content of an element" is instead to be found in an attribute. This can be done by slightly altering the definition of HyNames, to allow the renaming of #CONTENT to an attribute name.
We also need to add language stating that element content that contains element markup cannot be moved into an attribute list, and that any lextype requirements on the content are applied to the new attribute.
The list of events should allow actions to be labeled with whether they occur before or after the activity. Modify the architectural form for the activity element to include:
when (before | after)
When=before says that tracking occurs before the
action is taken. When=after says that the tracking
is taken after the action has been performed.
We could also, if we're ambitious, add the ability to attach a "permission function" to add access permissions to activity tracking. This would enable the definition of activity elements that could enable or disable an action to take place. This is a hook for generalized access control. As with all activity tracking, we can't require implementors to implement such restrictions, but we can allow them to be documented in publicly defined notations. This would take the form of another attribute added to the activity element:
access (access | noaccess) "noaccess"The value
access would label the
activity element as a permission function, while the default value,
noaccess, would leave it as a normal activity tracking element.
We've heard rumors that replacement of HyQ with the DSSSL query language is under consideration. The DSSSL formal definition is more complete, and the syntax, being based on an existing language, is less sui generis. Nonetheless, it is hard to express unqualified support for removal of such a critically needed feature that some people have already implemented, based on the published standard. On the other hand the DSSSL language is more powerful and complete.
Given the problems with eliminating HyQ, we suggest the definition of an appropriate public identifier for DSSSL queries, and insertion of a normative reference to DSSSL into the HyTime standard.
Up for argument: the proposal that HyQ be explicitly deprecated, or advocated only for simpler queries (where for instance the DSSSL non-ESIS data model is not critical).
Currently HyQ does not provide an easy way to select by fully qualified GI. Suggest adding a new property, FQGI which returns the GI of an element, preceded by the SGML space character role and the FQGI of its ancestor (if any). For example in the following:
<doc> <p> <it>hi there</it></p></doc>the IT element would have the FQGI "DOC P IT"
Currently the reftype attribute serves two functions:
These two important functions are different. We urge that the two functions be separated, by defining a new all-ref attribute, refmodel, that would have exactly the same definition as reftype, except that it would perform only function 2. The reftype attribute would be redefined to only perform function 1. If backward compatibility is a critical issue in this case, the new attribute could be enabled by setting an option that would allow refmodel, and disallow option 2 behavior on reftype destinations.
This should ease an implementor's tasks by separating functions, and also make the purpose of the individual options simpler and easier to understand.
This falls in the class of "convenience features that are almost important enough to be absolute requirements"
Currently the dimref mechanism is not suitable for creating "abutting schedules," in which a series of extents follow one another without gaps. Because extent endpoints are included in the extents, and dimrefs copy coordinate values, the dimref mechanism alone is not suitable for creating such schedules. The closest thing that can be created are schedules with a single quantum overlap. While this is not a fundamental limitation of HyTime, since HyFunk and HyOp can be used to avoid it, the limitation makes a common operation needlessly complex. We propose to add a new attribute, "adjacent", to dimref. This will, for an endpoint of an extent, return that adjacent quantum of the relevant axis that lies outside the event. This attribute would be defined as follows:
adjoin (adjoin | noadjoin) noadjoinadjoin would invoke the new semantics described above, while noadjoin would be processed as currently defined.
HyTime does not currently explain how these sorts of structures should be addressed. This should be handled as suggested above in the consideration of alternatives to HyQ, by a normative reference to DSSSL.
We suggest that HyOp be deprecated or dropped. It is identical in power to HyFunk, but notationally less convenient, and should be dropped on account of its redundancy. HyFunk itself could be folded into HyQ, further simplifying the syntax. If the DSSSL is adopted into HyTime, this is not a very pressing issue, since that integration is already in place in DSSSL.
We are not competent to recommend repair here. The rules as specified for the individual attributes seem as if they will not combine well, but after hours of work spent on this, we have been unable to determine what exactly the current rules describe, and whether they are consistent or not. We feel strongly that value defaulting in HyTime should be related to tree ancestry rather than to linear position in an encoded document, as requiring linear scanning makes implementation more difficult, especially in a networked environment where the transmission of partial documents is a desirable implementation technique. This does not seem to be true of the current rules.