OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: partial review of Ch.9 -- Defaults

All --

(See also my follow-up message about processing this stuff.)


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.


[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


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


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, 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 =====


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]