cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: partial review of Ch.9 -- Defaults
- From: Lofton Henderson <lofton@rockynet.com>
- To: CGM Open WebCGM TC <cgmo-webcgm@lists.oasis-open.org>
- Date: Sun, 04 May 2008 12:41:28 -0600
All --
(See also my follow-up message about processing this stuff.)
SCOPE OF THESE COMMENTS.
==========
I started with the assumption that the TC will retain the requirement for
XML-coded defaults stuff. These comments are only about the
defaults stuff in Ch.9. I have *not* tackled these issues
yet:
1.) how the XML defaults stuff is packaged -- does it go into a single
ACI file along with font-sub stuff? Or exist in a separate file
that is only defaults stuff? Or be part of XCF? Or
what?
2.) how does the ACI file(s) get invoked or attached to the viewer (or
metafile)?
We will isolate and resolve these issues separately.
So basically I'm looking at 9.3.5 through 9.3.19.
REFERENCES.
==========
[1]
http://docs.oasis-open.org/webcgm/v2.1/cd01/WebCGM21-Config.html
[2]
http://www.oasis-open.org/committees/download.php/26392/WebCGM%202_1%20Requirements.htm
[3]
http://www.oasis-open.org/apps/org/workgroup/cgmo-webcgm/download.php/26099/Attributes_Table.pdf
REQUIREMENTS & USE CASES.
==========
I checked Ch.9 against the requirements [2], as well as the use cases and
specific agreed items for the Defaults stuff [3].
Result: Ch.9 accurately implements the decisions recorded in [2]
& [3].
Use cases: My searching finds that these cases are to be
addressed.
a1.) In V1 or V2 files, it is not possible to control things like LINE
CAP, which is a V3 CGM element. Viewers have to select a treatment
at random. There is desire to be able to specify consistent and
uniform treatment.
a2.) (A variant on a1.) In V3/V4 files, the CGM:1999 specified
default for things like LINE CAP is: 1,
"unspecified". (CGM:1999 did this so that behavior of
viewers would be backward compatible. I.e., the rendering of
an otherwise identical file would not change purely based on
"V1" versus "V3" in the metafile version.)
There is desire to be able to specify a consistent and uniform
default.
b.) The CGM line types 1..5 (solid, dash, dot, dash-dot, dash-dot-dot)
are generic in the sense that they only need to be recognizably per the
description (e.g., dash-dot). Similarly for the 6 generic hatch
styles. There is desire to be able to specify consistent and
uniform treatment.
Issue 9d1: Agreed? These are the cases that we intend to
support? (Recommendation: yes).
Question 9d2: Should the linetype and hatchstyle defaults of #b
apply for metafiles of all CGM versions? (Recommendation:
sure, why not?)
Note the issues 9d11 and 9d12 below. As defined, the
lineEdgeTypeDef and hatchStyleDef contain more generality than necessary
to satisfy the above Use Cases as stated (or as I understood them).
That's okay if it's what people want, but let's be explicit about it in
that case. (Or re-parameterize otherwise.)
REVIEW: ISSUES & COMMENTS
==========
Comment 9d3: Although there is some general reference in 2.5.2 and
2nd paragraph of 9.1 to the motivations -- a1,a2,b -- I think Chapter 9
would be more easily understood if the exact descriptions (like #a1 - #b)
were included. Recommendation: put some text like that at the
beginning of 9.3.5. (Agreed?)
Comment 9d4: If 9d3 is agreed, then we should structure the bullet
list of 9.3.5 accordingly and group it with the explanatory text.
(Agreed?)
Comment 9d5: All of these default-related items are actually
CGM:1999 Attribute elements. They are not Style Properties.
Recommendation: rename the 'defaultStyleProp' element to
'defaultCGMAttribute' (or something similar). (Agreed? [Or
suggest better alternative.])
Question 9d6: The document structure of the subsections 9.3.5 -
9.3.19 is "flat". Whereas 9.3.6 could logically be
considered to be 9.3.5.1, etc. Should we add more document
structure? (Recommendation: none, I don't care a lot.
What do you like?)
Editorial 9d7: "line cap indicator" in 9.3.14 is a
typo. It should be "line index", to match the XML
attribute name 'lineIndex'.
Question 9d8: In fact, in 9.3.14 why not lineTypeIndex or
lineTypeIndicator or something like that. Do people prefer terser
or more meaningful names?
Issue 9d9: 9.3.15 says that dashLength is defined in NVDC
units. Is that correct? If you look at CGM:1999 (7.4.17)
these numbers are pure integers. The units are attached by the
repeatLength item. Recommendation: dashLength should be
unitless integers. (Agreed?)
Comment 9d10: 9.3.14 and 9.3.15 are under-defined.
Specifically: it is implied but not unambiguous how the sequence of
"repeatable string" comprises the 'list of dash elements' (of
CGM:1999 7.4.17); it is not restricted to non-negative; it is not defined
what 0 (zero) means. Recommendation: either explicitly here
or by reference to 7.4.17, these things should be disambiguated.
(Agreed?)
Issue 9d11: The lineEdgeTypeDef element actually allows all of the
generality of the corresponding CGM:1999 element. For example, it
could allow the redefinition of LineType 3 (dash-dot) to look like 'dash'
(LineType 2). The stated purpose is to give uniform appearance to
1..5. Do we want to allow the generality to change the appearance
from the generic description? Or do we want to try to parameterize
so that this could not be done? E.g., lengthOfDash, interDashGap,
interDotGap, etc. Recommendation: none. (What do people
want? I.e., how do you want to refine the requirements and use
cases? Generality? Or restrictiveness?)
Issue 9d12: The hatchStyleDef element of 9.3.16 has the same issue
as 9d11 -- sufficient generality so that HatchIndex 1, "horizontal
equally spaced parallel lines" could end up not equally-spaced, or
could even be exchanged with another of the pre-defined (or something
altogether different). Recommendation: none. (What do
people want? I.e., how do you want to refine the requirements and
use cases? Generality? Or restrictiveness?)
Editorial 9d13: In 9.3.16, change "line cap indicator ...
1-5" to "hatch index ... 1-6".
Comment 9d14: In 9.3.17, the units should be stated -- NVDC.
(Agreed?)
Comment 9d15: In 9.3.18, it should be explicit that gapWidth
entries are positive integers -- this is what the CGM:1999 Formal Grammar
says. (Agreed?)
Editoral 9d16: There are misspellings, as well as cases where
the terminology could be clarified or better aligned with CGM:1999.
Recommendation: the editor be given discretion to make these changes,
without enumerating them individually. (Agreed?)
===== end =====
Regards,
-Lofton.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]