| 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.