| TITLE: | Disposition of comments on SC34 N0216: PDAM1 to ISO/IEC 10179:1996, Extensions to DSSSL |
| SOURCE: | SC34/WG2 |
| PROJECT: | JTC1.34.15.06.01.01 |
| PROJECT EDITOR: | S. Kaida |
| STATUS: | Document for SC34 meeting in Orlando |
| ACTION: | |
| DATE: | 2001-12-10 |
| DISTRIBUTION: | SC34 and Liaisons |
| REFER TO: | SC34 N0216, N258 |
| REPLY TO: |
(1) I suspect Annex C has a typo "CICAGO" perhaps is supposed to be "CHICAGO" in the example.
--> Accept.
(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.
--> Accept. "c" means "technical corrigendum". Explanations of the use and utility will be added.
(3) The use and utility of the table could be explained in an introductory paragraph or two
--> Accept.
(1) In the headings of Annex B, C, D, E and F, there should be the indication of "Informative".
--> Accept.
(2) In 12.6.28.5, 12.6.28.6, 12.6.28.7, "disply" should be replaced with "display".
--> Accept.
(3) In Annex C,
just before example, the incorrect tagging <P< P> should be replaced with <P>.
--> Accept.
(4) In clause 3. and 4. of Annex B, each unordered list item should be added with some explanations.
--> Accept.
(5) In Annex D, the Grove Plan and SGML Property Set should be added with some explanations.
--> Accept.
(6) In Annex E, the large table should be split into several parts for rendering on pages of ISO documents.
--> Accept.
(7) In Annex F, types and relational characteristics should be clarified in the table. The descriptions "<unknown>" should be "unknown".
--> Accept.
(1) 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.
--> Accept. Inappropriate descriptions will be corrected.
(2) Annex B:
(2a) 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, 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.
--> The 'quantity' type and 'length' type are defined in the existing DSSSL (see 8.5.7.1 and 8.5.9 of ISO/IEC 10179).
(2b) 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.
--> The 'language' type is the type defined in 12.6.6 of the existing DSSSL. Regarding 'symbol' type, see 12.4.7 of the DSSSL. Regarding 'style' and 'address' types, see 12.4.3, 12.4.5 and 12.5.8 of the DSSSL.
(2c) 'culumn-set-model' should be 'column-set-model'
--> Accept.
(3) Annex C:
(3a) 'CICAGO' should be 'CHICAGO'
--> Accept.
(3b) 'VIRTICAL should be 'VERTICAL'
--> Accept.
(1) Overall
(1a) This document is not suitable for publication as a PDAM because: 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.
--> According to the appropriate comments from UK and other national bodies, the PDAM text will be revised to be an FDAM text which can conform to both ISO practice and to the editing conventions.
(1b) The proposed additional functions are not formally defined, and there is no formal definition of the proposed DSSSL grove.
--> The additional functions should be defined in the same manner as the definitions of existing functions, for harmonizing with the existing DSSSL text (ISO/IEC 10179).
(2) Clause 12.2.1
(2a) 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."
--> Accept and thank you.
(2b) A formal specification of the API is needed, and must be referenced from the sub-clause.
--> Reject. The API specification is outside the scope of this amendment. It should be discussed in a future project.
(3) Clause 12.3.5
(3a) Change "formating" to "formatting" (change needed throughout document)
--> Accept.
(3b) 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".'
--> Accept and thank you.
(4) Clause 12.3.6
The wording of this section should be improved as follows:
"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"
--> Accept and thank you.
(5) Clause 12.6.28.5
The wording of this section should be improved as follows:
"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."
--> Accept and thank you.
(6) 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."
--> Accept and thank you.
(7) 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."
--> Accept and thank you.
(8) 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."
--> This amendment is an extension to DSSSL responding to the user requirements for Sound-Voice, Animation, etc. The rewording is Acceptable.
(9) 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 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."
--> The input is outside the scope of this amendment. It should be discussed in a future project. The rewording is Acceptable except "...may be aan tomic...".
(10) 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."
--> The rewording is Acceptable.
(11) Annex B
This annex is not written in such a way as to make it comprehensible to
users of the standard.
--> Accept. Annex B will be revised to make it more comprehensible.
(12) 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 C" will be changed to "Annex C (informative)". The FPIs are based on the user requirements for line-breaking-method and line-composition-method.
(13) 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.
--> One purpose of Annex D (informative) in not to specify grove plans but to show schematically the relationship among the modules of grove plans defined in 9. of the existing DSSSL. Another purpose of the Annex D is to clarify the elements and attributes of the property set defined in 9. of the DSSSL. Those purposes will be explained in the additional texts in the Annex.
(14) 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.
--> "Annex E" and "Annex F" will be changed to "Annex E (informative)" and "Annex F (informative)" respectively. They are clarifications of flow object classes and characteristics and values of characteristics, being based on user requirements.