RE: [cgmo-webcgm] ISSUE 9d11: Should lineEdgeTypeDef be generalized or focused?

[Lofton Henderson <lofton@rockynet.com>]

At 04:30 PM 5/8/2008 -0700, Cruikshank, David W wrote:
> I'm
> in favor of generality and I think our use cases support
> this:
>  
> From the requirements document
> (http://www.oasis-open.org/committees/download.php/26392/WebCGM%202_1%20Requirements.htm)
> In another usage, LINE AND EDGE TYPE DEFINITION (and similarly hatch
> style) default setting could allow a specific exact dash style to be
> assigned to the generic CGM line types 1,2,3,4,5.
>  
> I don't think that use case
> limits us from doing anything.

Of course a Use Case does not *limit* the design you choose to satisfy it
-- it only defines a minimum.  However, (IMO) good design principles
suggest that the design should be the smallest, simplest functionality
necessary to satisfy the use case.

That, at least, should be our continuing design criterion in
WebCGM.  

So the minimal design to satisfy that use case is:  cycle-length,
length-of-dashes, and maybe something-about-dot.

The current capability of LineEdgeTypeDef is:  ability to redefine
generic line types 1..5 to look like any conceivable line type.  (So
... taking it ad absurdum ... you could make line type 2..5 all be solid;
or even empty/invisible?)

>  
> From the attributes table
> (http://www.oasis-open.org/committees/download.php/26099/Attributes_Table.pdf)
>
> The ability to be able to define the sizes of
> the dash, dots, spaces, line spacing (for hatches) for the line types
> that are pre-defined. This is useful to make lines look consistent across
> viewers and hard-copy versions.
>
> While the second sentence
> doesn't capture the whole use case, 

It is *exactly* the use case that I thought we have approved so
far:  we wanted the rendering of the generic types (solid,) dash,
dot, dash-dot, dash-dot-dot to look uniform across viewers.

What it does not capture, perhaps, is the (expanded) use case that you
have in mind in requesting "generality".  We apparently
have interpreted the use case differently.

> the
> first sentence implies that control over the sizes of dashes, dots, and
> gaps is required.
>
> Perhaps we need to revise the
> use case to include alignment of the visual appearence of V1 and V2 files
> when used in conjunction with V3 files in an
> application.

I'm not understanding what this means in concrete, what's-in-the-metafile
terms.


> Do
> we need to update the use cases in the requirements and/or the attributes
> table?

I think it is the right way to proceed.  When I reviewed and
approved the attributes table, and the requirements, what I had in mind
is the ability to make the generic line types 1..5 look uniform across
implementations, but still look like:  solid, dash, dot, dash-dot,
dash-dot-dot.  (Do we really need to address 'solid'?).

I do not necessarily oppose the generality.  For example:

PRO:  It is easiest to implement, because every CGM:1999 viewer
already has the code for LETD.  (A more restrictive parameterization
would require a little more new, to translate the parameters into the
LETD set.)

But then...

CON:  A 2.0 viewer that might get a very different picture from a
2.1 viewer, and that picture might disagree with what CGM:1999 says it
should look like.  (If the aci directives changed the generic
pattern rather than simply making it more precise.)  

But then again...

Contra that CON:  On the other hand ... one can do that sort of
thing with some stroke properties with the Style Properties in 2.0 --
applied at the Picture level -- and can do it to line type in 2.1 with
the newly added 'stroke type' Style Property.

-Lofton.

 

---

From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Monday, May 05, 2008 10:51 AM
To: CGM Open WebCGM TC
Subject: [cgmo-webcgm] ISSUE 9d11: Should lineEdgeTypeDef be generalized or focused?

From my review of Ch.9 defaults stuff,
http://lists.oasis-open.org/archives/cgmo-webcgm/200805/msg00005.html ,
one particularly substantive issue stands out:

ISSUE 9d11: Should the lineEdgeTypeDef ACI item be generalized or restrictive?

Discussion:  The lineEdgeTypeDef element in the current (CD) Ch.9 ACI 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 use case is somewhat lacking in detail, but *seems* to indicate that the purpose is to give uniform appearance to the generic predefined line types, 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.  More discussion is needed from users and vendors to refine the desired capabilities in the use cases.  In favor of generality? Or in favor of restrictiveness?

Note:  Presumably ISSUE 9d12 -- same issue about hatchStyleDef -- will have the same resolution.  (Although it is conceivable that the use cases *could* lead to different resolutions.)

[1] http://docs.oasis-open.org/webcgm/v2.1/cd01/WebCGM21-Config.html