[cgmopen-members] product info assessment -- 2nd draft

[Lofton Henderson <lofton@rockynet.com>]

CGM Open members --

Here is a 2nd draft of my analysis and proposal to get product information 
posted expeditiously.  Let's discuss this during the 8/22 
telecon.  Especially look at the section, "Proposed way forward".

Also I have attached a prototype/sample of what a viewer pro-forma might 
look like.

-Lofton.

Title: Sample viewer pro-forma

Product

Acme XyzView 2.0 for Windows.

Introduction

This checklist describes the conformance of the subject viewer product to the WebCGM specification, according to its performance on the WebCGM Test Suite.

The functionality is coarsly divided with two questions: static graphics and dynamic behavior. All viewers should be able to render the static graphics, but some viewers -- e.g., printers, or standalone interactive viewers in an environment without a Web browswer -- are inherently incapable of executing the dynamic tests.

For each of the categories, dynamic and static, there are a small number of more detailed questions which summarize the basic functional categories or modules. Each category links to a specific set of tests. "Yes" means all tests are passed, "No" means at least one test is not passed for that module. "Comments" link to optional product supplier comments about the product's behavior on the module.

WebCGM viewer pro-forma checklist table

All-functional overview
Key	Description	Yes	No	Comments
1.	Supports all dynamic functionality -- for all modules below, passes all (~25) tests.
2.	Supports all static functionality -- for all modules below, passes all (~225) tests.
Dynamic functionality
Key	Description	Yes	No	Comments
1.1	Basic linking -- inbound and outbound, whole-file targets, fragments, multi-links
1.2	Basic linking behaviors -- frames, highlighting, zooming
1.3	Advanced fragments -- all forms, browser-bug workaround, etc.		x	LRH-1.3
1.4	Interaction -- pick region, screentips, etc
1.5	Other APS -- para, subpara, level, content model
Static functionality
Key	Description	Yes	No	Comments
2.1	Line elements -- geometry of all line elements, support of all line-element attributes. (subdivide finer? e.g., geometry vs. attributes? simple vs. curves?)
2.2	...etc...
2.3	Basic text support -- all basic text stuff and basic text attributes
2.4	Full character set support -- unicode etc. (is this worth separate breakout?)
...	... etc -- maybe 10-15 lines total in this static-graphics part ...

---

Comments from table

LRH-1.3: Viewer does not do multiple pictures (deprecated in WebCGM 1.0 2nd Release).

---

Test lists

Dynamic modules

1.1-tests: linking-basicH2C-BE-01, linking-basicC2H-BE-02, linking-basicC2C-BE-03, linking-basicC2P-BE-04, linking-selectId-BE-05, linking-selectName-BE-06, linking-anyURI-BE-07, linking-multiLink-BE-08

1.2-tests: behavior-picBlankC2C-BE-01, behavior-picReplaceC2C-BE-02, behavior-picBlankC2H-BE-03, behavior-picTargetC2H-BE-04, behavior-objHighlight-BE-05, behavior-objHighlightAll-BE-06, behavior-objViewContext-BE-07

1.3-tests: fragment-idC2H-BE-01, fragment-multiPic-BE-02, fragment-fiveForms-BE-03, fragment-browserBug-BE-04*

1.4-tests: interact-pick-BE-01, interact-pickRegion-BE-02, interact-screenTip-BE-03

1.5-tests: otherAPS-para-BE-01, otherAPS-para-BE-02, otherAPS-subPara-BE-03*, otherAPS-subPara-BE-04*, otherAPS-layer-BE-05*, otherAPS-contentModel-BE-06*

Static modules

2.1-tests: ..., ELLARC01, ELLARC02, ELLARC03, ELLARC04, ELLARC05, ...

2.2-tests:

...etc...

---

References

Title: Website Vendor Info -- Issues

Website Vendor Info -- Issues & Plan

2nd Draft: 18 August 2002
By: Lofton Henderson

Foreword

This is an initial step to try to get us (CGMO members) moving forward with the CGM product info project for our web site. This second draft is the same as last week's first draft in "Details", but "Proposed way forward" is elaborated, in anticipation of teleconference.

Contents

• Introduction
• Details
  • Summary of vendor-product list
  • Assessment matrix concept -- pro-forma
  • Product categories needing assessment
  • Pro-forma building blocks
• Proposed way forward
• References

Introduction

At Frankfurt TC meeting, we made a decision about CGM products in for CGMO members. Here's what we said (according to minutes):

A table of vendor product information was complied by Bruce Garner. The committee concluded that we should include a matrix of supported functionality for each application. Each vendor would fill out a matrix of capabilities. Each category of product (viewer, editor, generator) would need different capabilities demonstrated in the matrix. To validate the information, the test suite needs to be broken down into groups that test each area. No actions were assigned, but each of these activities needs to be addressed.

Bruce has produced a refinement of the table, and basically we have the basic product information that we need. Except we have made no progress on the matrix of supported functionality -- what I'll call the Assessment Matrix.

If we wait until all of this is done -- all of the forms designed and all of the forms are filled out by vendors -- it will be many months. So let's look at the details and try to make an expedited solution, which still gets us where we want to be -- vendor member product information, but with some accountability.

Details

Summary of vendor-product list

Here are the product categories, along with the number of products in Bruce's table:

1. Analysis: 1 product from 1 vendor.
2. Content management: 1 product from 1 vendor.
3. Format conversion: 13 products from 5 [4*] vendors.
4. Generator library: 4 products from 2 vendors.
5. Graphics editor: 7 products from 5 [4*] vendors.
6. Interpreter library: 2 products from 1 vendor.
7. Parsing libraries: 1 product from 1 vendor.
8. Presentation graphics: 1 product from 1 [0*] vendor.
9. Printing software: 5 products from 2 vendors.
10. Services - consulting: 2 products from 2 [1*] vendors.
11. Services - customization: 1 product from 1 vendor.
12. Viewers: 7 products from 3 [2*] vendors. (See note 2.)
13. Viewer/redliner: 2 products from 2 [1*] vendors.

Note 1: The notation "5 [4*] vendors" means that only 4 of the 5 vendors currently qualify for posting, because of current CGMO membership status.

Note 2: I'm suspicious that some vendor(s) may be missing from this list.

Question. How does a parser differ from an interpreter library?

Question. What is "Presentation Graphics"? Is it functionally the same as "Graphics editor"?

Assessment matrix concept -- pro-forma

(Reminder, the assessment matrix is for self-assessment by vendors.)

What is the purpose of the assessment matrix? It is sort of like an Implementation Conformance Statement pro-forma -- it says what has been implemented and what has not. For example, for viewers we could add an implementation column to the WebCGM PPF -- "yes", "no". Or we could make a table of each of the ~250 tests in the WebCGM test suite (TS).

We decided at Frankfurt that we don't want to be this detailed in our assessment matrices, but want to summarize at a higher level. For example, for a viewer assessment pro-forma, we could take the ~250 tests of the WebCGM TS, and lump them into 20 or so bigger categories, and put those in the assessment matrix with columns for "yes", "no", "comments". (Each category/table-row would link to a list of those TS tests that it subsumes.) Examples:

• Full support of line elements and line attributes (this one ought to be self-explanatory).
• "Full support of basic text attributes" might include all of the stuff like alignment, required font support, rotation. I would probably break out "Character sets" (e.g., UTF-8 and UTF-16) as a separate category.
• "Full support of WebCGM hyperlinks" might consolidate a dozen or more of the dynamic TS tests. "yes" means that you pass them all. "No" means some non-pass, and then "comments" could link to your (optional) explanation.
• Or, we could partition finer -- basic hyperlinks and full behaviors -- but we need to be careful not to create too many categories.

Is this concept clear and agreed?

Product categories needing assessment

Here are some thoughts on the product categories and their assessment matrix considerations:

1. Analysis: YES
   • probably similar to viewer (conditionally: if it has a visual interface via a displayed CGM)
   • Plus: is error checking supported? how complete? what profiles or variants?
2. Content management: NO
3. Format conversion: YES
   • may be difficult to design assessment(s) -- much variety!
   • two flavors: to-CGM; from-CGM
   • To-CGM:
     • similar to generator -- what elements output?
     • what profiles?
     • known omissions in converting input functionality
     • preserve high-level graphics primitives?
   • From-CGM
     • similar to viewer?
     • complete CGM support?
4. Generator library: YES
   • simple? "List anything that you can't generate:"
5. Graphics editor: YES
   • viewer assessment criteria
   • + generator assessment criteria
   • + round-tripping, "preservation of primitives"
     • this could be a copy of viewer matrix (20-25 categories summarizing WebCGM TS)
6. Interpreter library: YES
   • same as parsing libary pro-forma?
   • or is there a "functional equivalent" variant to the parser's "literal" philosophy?
7. Parsing libraries: YES
   • simple? "List anything that you can't parse and handoff to calling application"
   • or variant on viewer?
     • 20-25 questions/categories spanning 250 tests of WebCGM TS.
     • different question: "can you parse..." instead of "can you display..."
8. Presentation graphics: YES
   • is this the same as graphics editor?
9. Printing software: YES
   • same as viewer
   • except any dynamic functionality questions are "N/A"
10. Services - consulting: NO.
11. Services - customization: NO.
12. Viewers: YES
    • See proposed viewer pro-forma example
13. Viewer/redliner: YES
    • same as editor?

From this, it appears that:

• of the 13 product categories, 10 will need assessment pro-forma (matrix), 3 are "not applicable".
• it looks like the 10 can be built from a smaller number of building blocks -- some commonality

Pro-forma building blocks

Exploiting the commonality, it looks like we need to design and come up with a small number of distinct pieces, which we could then put together with some hopefully small amount of customizing "glue" for the different products. The simpler pieces (pro-formas) also are components in the more complicated ones.

1. Generator library pro-forma. Used by:
   • generator library
   • Editor pro-forma
   • transcoder (format converter to-CGM)
2. Parser & Interpreter library pro-forma.
   • parser & interpreter library
   • Viewer pro-forma
3. Viewer pro-forma. Used by
   • viewer
   • printer
   • Editor pro-forma
   • analysis
   • (variant for transcoder from-CGM?)
4. Editor pro-forma. Used by
   • Graphics Editor
   • Presentation Graphics
   • Viewer/redliner

It is still a little unclear about transcoder/converter, what we can reasonably expect. Perhaps: similar to the "preservation of primitives" stuff that we want in the editor pro-forma, we could have a "cross-format preservation" question in transcoders. For example, we want to know if a CAD format converter puts out all 2-point polylines instead of Bezier curves. Plus, of course, there should be question(s) about "any input functionality which is not converted".

Proposed way forward

1. Endorse this concept and this approach, or develop and endorse an alternative.
   • Agreed?
   • Else, propose an alternative if you disagree.
2. Get volunteers to design and review the pro-forma components.
   • Bruce has volunteered.
   • Who else will volunteer?
   • See accompanying sample viewer pro-forma
3. Finish the 10 needed pro-formas ASAP.
4. Decide on formatting issues (everyone -- see below), format and structure the information.
5. Post the information

I would like to propose a pragmatic 2-step approach to expediting the posting of the product information:

• Step-1. Put the product info (for qualified members) onto the Web site as soon as #3 above is finished, with a pointer to a blank pro-forma, and suggestion to the reader that they ask the product vendor for the information, and discuss it.
• Step-2. Each vendor has some period of time (is 30 days too short? other?) to complete the pro-forma, and then the blank ones are replaced with the completed ones

We need to decide on structure and format of the Web page(s). Some options:

1. Should we have Bruce's table as a single Web page, consisting of a single table? Example.
   • In column 1 we would have the product category, and maybe blank assessment pro-forma
   • In column 2 would be the vendor's name.
   • Column 3 would be the product info and links to vendor web site. (And eventually link to completed assessment pro-forma for the product.)

   Basically, this is just a HTML table version of Bruce's .doc file. There would be introductory/explanatory information as indicated for option 2..

2. Alternately, we could have an introductory page that explains what this is about, disclaims endorsement or implication of goodness, warns reader to ask the right questions (and ask vendor for assessment information per pro-forma), and would have a list of product categories. Each list item would link to an individual Web page (i.e., a page per product category). Each product-category page would be a table, probably needing 2-3 columns as above.
3. Does anyone want to propose any other alternatives?

References

1. Cleveland minutes DOM definition (available at http://www.cgmopen.org/meetings/cgmo_tech_cleveland_01.html)
2. Orlando minutes (availabe at http://www.cgmopen.org/meetings/cgmo_tech_orlando_02.html#review)
3. Frankfurt minutes (available at http://www.cgmopen.org/meetings/cgmo_tech_frankfurt_02.html)