ISO/IEC JTC 1/SC34 N258

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

SC 34 / WG 2

This document is submitted to JTC 1/SC 34 for information and to WG 2 for preparation of a disposition of comments report and recommendation on further progression of the work.                                              

SC 34 N 258

2001-10-04

SC 34 Voting Summary on JTC 1/SC 34 N 216

PDAM1 Ballot for ISO/IEC 10179: Extensions to DSSSL

According to  the JTC 1 Directives, Section 9.4.3

Consideration of successive CD/PDAM/PDISP/PDTRs (types 2 and 3) shall continue until the substantial support of the P-members of the committee has been obtained or a decision to abandon or defer the project has been reached.

SC 34 National Body Comments on N 216

Canada

(1) I suspect Annex C has a typo "CICAGO" perhaps is supposed to be "CHICAGO" in the example

(2) the table in Annex E includes entries indicated with "c" yet not defined in the legend; also, the use and utility of the table could be explained in an introductory paragraph or two

(3) the use and utility of the table could be explained in an introductory paragraph or two

Japan

1. In the headings of Annex B, C, D, E and F, there should be the indication of "Informative".

2. In 12.6.28.5, 12.6.28.6, 12.6.28.7, "disply" should be replaced with "display".

3. In Annex C, just before example, the incorrect tagging <P< P> should be replaced with <P>.

4. In clause 3. and 4. of Annex B, each unordered list item should be added with some explanations.

5. In Annex D, the Grove Plan and SGML Property Set should be added with some explanations.

6. In Annex E, the large table should be split into several parts for rendering on pages of ISO documents.

7. In Annex F, types and relational characteristics should be clarified in the table. The descriptions "<unknown>" should be "unknown".

Norway

The language throughout this PDAM is in need of editing, with respect to both grammar and orthography. The text should not be added to the standard without having been edited.

Annex B:

·                     Why is the 'quantity' type introduced? its place in the numeric tower (see section 6.2.1 of R5RS) needs to be made clear. also, the   relationship, if any, of the 'length' type with the rest of the    numeric types must also be made clear.  it is very important that  the relationship between the numeric types as defined in R5RS is   retained in DSSSL, and that extensions fit cleanly in with the existing types.

·                     why is a separate 'language' type needed? what is the difference  between instances of this type, and instances of the 'symbol' type? The same applies to the 'style' and 'address' types.

·                     'culumn-set-model' should be 'column-set-model'

Annex C:

·                     'CICAGO' should be 'CHICAGO'

·                     'VIRTICAL ahould be 'VERTICAL'

United Kingdom

Overall

This document is not suitable for publication as a PDAM because:

a) The language used for the proposed amendment to the standard does not conform to either ISO

practice or to the editing conventions employed in ISO/IEC 10179.

b) The proposed additional functions are not formally defined, and there is no formal definition of the

proposed DSSSL grove.

Clause 12.2.1

The wording of this new sub-clause could usefully be improved to read:

"A DSSSL processor generates a flow object tree. The flow object tree contains information about

the results of applying formatting specifications. DSSSL style editors operate on the flow object

tree through an abstract application program interface. This API shall report the following

information:

- character, glyph and glyph-annotations

- line composition

- paragraph composition

- column-set composition

- page composition

- document composition

- documents' volume composition

The abstract API will include dynamic information relating to the document under construction.

DSSSL may define a core interface for page composition. The API architecture is system

independent."

A formal specification of the API is needed, and must be referenced from the sub-clause.

Clause 12.3.5

Change "formating" to "formatting" (change needed throughout document)

Change:

'Display area include display areas and inline areas. Inline area also include conceptualized

display area. Then DSSSL will define inline-display area what is display area is included by inline

area.'

to:

'Display areas may include other display areas as well as inline areas. Inline areas may also

include conceptualized display areas known as inline-display areas. DSSSL defines an inline-display

area as a "display area included within an inline area".'

Clause 12.3.6

The wordingofthissection should beimproved asfollows:

"The concept of an attachment creates a link between one of display area or inline area and

an attachment area. The attachment area for a display area shall be outside the display area.

The attachment area for an inline area shall be within the inter-line area between the current

line and the immediately following line, or the border adjacent to the next display area.

DSSSL, therefore, has the following formatting areas:

Display area

Inline area

Inline-display area

Inter-line area

Attachment area (for display area)

Inter-line attachment area "

Clause 12.6.28.5

The wordingofthissection should beimproved asfollows:

"This clause defines an extended-online feature.

The display-window flow object class specify an abstract size for the display frame of an online

display. The display-window flow object class may get the top position of current scroll flow object

classes as its root class. The display-window flow object class may be a recursive flow object

class. It has a single principal port, which accepts any displayed flow objects.

This flow object has the following characteristics:

-- frame-type: one of the symbols window, dialogue, note, caution, alarm or warning. It specifies

the type of window to be displayed. The initial value is window.

-- frame-size: one of the symbols maximum-size, good-size or minimum-size. It specifies the

relative size of window to be used online display. The initial value is good-size. This actual values

used to represent this characteristic will depend on frame-type characteristics and display

devices."

Clause 12.6.28.6

This clause should be reworded:

"This clause defines an extended-online feature.

The pop-up flow object class provides information relating to a pop-up area, or the edge area of

the current window frame. It has a single principal port, which accepts any displayed flow objects.

This flow object has the following characteristics:

-- information-type: one of the symbols anything, warning, error, additional-information, note,

origin-of-link, voice-source, glyph or semantic. It specifies the type of information to be placed into

the pop-up window or the edge area of the current window on online display. The initial value is

anything.

Note: This flow object can be used to display any information, including position data relating to the

grove structure."

Clause 12.6.28.7

This clause should be reworded:

"This clause defines an extended-online feature.

The dialogue flow object class is used to specify interactive dialogues for online display. The

dialogue flow object class shall be placed at the front top of the screen display within a display-window

flow object class. Dialogue flow object classes be treated as an interactive flow object

class. It has a single principal port, which accepts any displayed flow objects.

This dialogue flow object has the following characteristics:

-- dialogue-type: one of the symbols request, acknowledgement, select-objects, select-of-list or

interaction. The initial value is acknowledgement.

-- dialogue-return-type: one of the symbols yes-no-cancel, yes-no, OK-ng, OK, words, phrase or

information. The initial value is OK."

Clause 12.6.29

This clause does not deal with the processing of printable documents, for which DSSSL is specifically

designed, and should not, therefore, be included in the standard. If this clause is retained it should be

reworded:

"This clause defines the sound-voice-and-animation feature.

The sound-voice and animation flow object classes is used for sounds, voices and animations

stored within a external entity. Flow object of these classes may be inlined or displayed on online

display. This flow object is atomic."

Clause 12.6.29.1

In addition to the objection raised for the whole clause, this sub-clause does not make sense as it provides

no information on where the input should be directed.

If this sub-clause is retained it should be reworded:

"This clause defines the sound-voice feature.

The sound-voice flow object class is used to specify sound and voice data to be used in

conjunction with an online display. The sound-voice flow object class may be aan tomic object on

other flow object classes, and it may be recursive on itself, depending on the sound-voice system

being used. It has a single principal port, which accepts any flow objects.

This flow object has the following characteristics:

-- output?: boolean specifying whether the flow object shall be output rather than displayed and

inlined. This characteristics is not inherited. The default value is #t."

Clause 12.6.29.2

If this sub-clause is retained it should be reworded:

"This clause defines the animation feature.

The animation flow object class specify animation on online display. Animation flow object class

may be atomic object on other flow object classes. It has a single principal port, which accepts any

flow objects.

This flow object has the following characteristics:

-- output?: is boolean specify whether the flow object shall be outputed rather than displayed and

inlined. This characteristics is not inherited. The default value is #t.

Other specifications is system independent."

Annex B

This annex is not written in such a way as to make it comprehensible to users of the standard.

Annex C

There is nothing to stop users of the standard from assigning formal public identifiers to DSSSL constructs.

There is, however, no reason why FPIs currently need to be assigned to any component of DSSSL.

Therefore this annex should be removed from the proposal.

Annex D

All grove plans for SGML documents must be specified according to the rules specified in Annex E of

ISO/IEC 10744. A simple diagram is not acceptable. A formal definition is a minimum requirement. Some

form of explanatory text is also desirable.

Annexes E and F

These annexes do not add additional information to the standard. This information is best made available

via the website of a DSSSL user community.