GH Williams
98-11-08

The UK is disappointed not to be allowed adequate time to review the new draft before the meeting, so as to send in detailed comments. UK Experts hope to correspond with the editors over the next few months by e-mail.

However, the UK submits comments from one UK expert, Martin Bryan, who. has been able to spend some time with it. UK experts have a general concern that:

ISMID should clarify its relationship with both HyTime and DSSSL, and in particular should specify its semantic properties for document behaviour declaratively, in relation to a grove, rather than in the present procedural/imperative style.

Commrents from Martin Bryan.

Actually its base on HyTime rather than DSSSL: DSSSL is only one of two options for the expression language. Actually I was reviewing it on my way to Madrid when you sent your messages. My comments, which you might like to combine with yours, are as follows:

The conformance statement claims that systems may support "either" the DSSSL expression language or HyFunk, but the HyTime support declarations listed later requires support for HyFunk, which implies systems must either support HyFunk on its own or both HyFunk and DSSSL.

The conformance statement also states that an ISMID application shall "be limited to the HyTime modules and options listed in the ISMID HyTime support declarations". This seems unnecessarily limiting as there may be other HyTime functions that an application needs to use, such as the timing/calendaring and rendering functions, for processing contained objects. The real requirement is that applications must at least support all of the functions listed in the support declarations.

The restriction on the permitted types of location to just nameloc and treeloc is worrying. In particular relative locations (relloc) would seem to be better suited to editing ISMID structures than treeloc, whose values change every time the document is edited. Also you may need a mixed location, so that you can go from a named node to one of its relatives as the safest way of identifying objects in an editable environment.

I am confused be why the Modify Container Object is not allowed to declare any modifications to VariableDeclarations, but you are allowed ot modify those associated with external objects using the ModifyExternalObject element.

I am concerned that control objects can only reference containers as their parent object. This make it impossible to have controls that scroll with the data. Here I am thinking of controls that are associated with hotspots in text, perhaps is the form of a control object placed in the margin at points where there sidenotes, warnings or lists of links that need to be displayed when a user requests their display by placing the pointer on the relevant control object.

I note that a Stimulus cannot reference the SystemChain, only a ResponseChain. Therefore you cannot develop "Reset system" controls.

The definition of end suggests it should be part of the model of the mid element type, but in fact, according to the Abstract IADD Subset it is only ever used to end a control flow construction (if, while or switch). The wording should be changed to indicate this if the use in the AIS is correctly stated, but it should be noted that the AIS provides a different model for the control flow elements than the text does, as the models shown in the text do not include the end element.

In Annex A the Abstract IADD Subset is referred to with the acronym IAS, which does not fit the title properly. It also contradicts the name assigned to the notation and the associated parameter entity, where AIS is used. The public identifier for the AIS parameter entity is also invalid as it contains no owner identifier. -// should be replaced by ISO/IEC.... when a number is assigned to ISMID by ISO.

It is not clear how "A conforming IADD shall declare and defined the semantics of each stimulus" in an interchangeable format.

In Annex B, under Image stimuli, there is a ? after OnLoadComplete. This does not make sense in an OR group defined within a parameter entity.

At a more editorial level my comments are:

In all references to the refrange attribute I would suggest that "followed by the letter B" be expanded to "followed, after a separator, by the letter B" to make it clear that the B is a separate token from the name of the parent element.

The second paragraph under the heading Create an External Object should be deleted.

Under Execute Response Chain change rspchref to ResponseChainRef (or vice versa)

Under Break Statement change "is" to "can be" as the break element is optional. Also note that the name of the element is in upper and lowercase in the element declaration but in lowercase only in those models that refer to it. (In general the editors need to go through the document and apply a consistent set of rules for capitalization. Other elements suffer from the same problem, e.g. End)

Inconsistent use of names also requires looking into. Expression is sometimes abbreviated expr. In particular the Abstract IADD Subset needs checking as it still refers to vardecl and argdecl.

Annex A contains some duplicated periods. It also looks as it if could do with some indenting of nested lists. It has "dedlared" in place of declared at one point.

Annex B contains ISMB in place of ISBN, and OnOnn within the definition of Caption, which needs reviewing.