TITLE: |
Summary of Voting on SC 34 N 216 - PDAM1 to ISO/IEC
10179: Extensions to DSSSL |
SOURCE: |
SC 34
Secretariat |
PROJECT: |
|
PROJECT EDITOR: |
SC 34 / WG 2 |
STATUS: |
|
ACTION: |
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. |
DATE: |
|
DISTRIBUTION: |
SC34 and Liaisons |
REFER TO: |
|
REPLY TO: |
Dr. James David Mason
|
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
P-Member |
APPROVAL OF THE
DRAFT AS PRESENTED |
APPROVAL OF THE
DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED |
DISAPPROVAL OF
THE DRAFT FOR REASONS ON THE ATTACHED |
Acceptance of
these reasons and appropriate changes in the text will change our vote to
approval |
ABSTENTION (For
Reasons Below): |
Brazil |
|
|
|
|
|
Canada |
|
X |
|
|
|
China |
|
|
|
|
|
Denmark |
X |
|
|
|
|
France |
|
|
|
|
|
Ireland |
|
|
|
|
|
Italy |
X |
|
|
|
|
Japan |
|
X |
|
|
|
Republic of Korea |
|
|
|
|
|
Netherlands |
X |
|
|
|
|
Norway |
|
X |
|
|
|
United
Kingdom |
|
|
X |
X |
|
United
States |
X |
|
|
|
|
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.
(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
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".
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'
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.