Discussion: Types of Scenarios

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

One thing I have been pondering is the types of scenarios that we have before us.  I'd like to know how others see such separations as useful, what ones they see, and what other flavors of scenario come to mind.

QUESTIONS
  1. Is this use of "operational scenario" understandable?
  2. Is there a better term?
  3. Is it useful to have the distinct term?

1. OPERATIONAL SCENARIOS

The notion of operational scenarios came up for me in working on the Template Scenario. I began to recognize this as an operational scenario, in that it confirms certain operational capabilities within and between implementations.  

This is about the ability to confirm and use certain arrangements, but it is not so much about what the arrangement is being utilized *for*, just that it is available and operational at some level.

Relative to office-productivity software, I think of these as more-horizontal than vertical (in the sense we use when we speak of vertical applications).  Maybe it is diagonal, rather than strictly horizontal, but the angle is less than 45 degrees from horizontal.  That's how I tend to visualize this kind of thing for myself.  The more it is underlying plumbing for enabling useful application of the software, the more horizontal/operational it is, in my thinking.

There are some very elementary operational scenarios for confirming operational capability (e.g., production/consumption of a minimal ODF text document and production/consumption of a minimal ODF text-document template).

2.  APPLICATION SCENARIOS

I want to contrast operational scenarios from application scenarios as we tend to be using the notion.  I don't propose to change the name of that usage, but I want to distinguish it.  Here's my thinking.

I contrast operational scenarios with application scenarios.  I realized today that application scenarios are more like use cases.  (I think of applications as what people are doing with productivity software even though it is common to speak of the software as [computer] application.  That is why I am squirrely about this term being used at multiple levels.)  These are more oriented to human activities.

If you look at the application-scenarios as they are described on the wiki and in the application-scenario template document, you'll see these are very much about what someone wants to accomplish with office-productivity software (e.g., take notes in a meeting, distribute them, review them).  There is a significant leaning toward human activity, work practices, and the need for interfaces that invite such activity.

My sense of the current application-scenario categories is that they emerged from work at Microsoft that was presented to the Document Interoperability Initiative.  The idea was to identify and have available archetypical documents that were representative of the particular categories.  The identification of categories was made by surveying documents and activities that had surfaced in real-world situations with users of office-productivity software.  That's my understanding of what Stephen is working on contributing in some form, possibly including archetypical documents in ODF format.  (I'm making this up.  Please correct me, Stephen.)

Our OIC scenarios go beyond just having archetypical documents to archetypical scenarios in which such documents are developed and used in their archetypical manner.

I don't think the plugfest documents that I've seen are archetypical in this sense.  They seem more contrived than that.  They are also clearly useful for confirming certain capabilities, but they strike me as designed specifically to test coherently-interoperable support of ODF features.

 - Dennis

MORE THINKING

This part is increasingly half-baked, but I wanted to find out how others think about feature-level testing.

3. FEATURE CHARACTERIZATION

A lot of tests don't fall into application scenarios, in my mind.  They aren't exactly for operational scenarios either.  Both operational scenarios and application scenarios depend on feature characterization down in the bowels, but these are different.

A feature characterization is just that: characterizing a particular feature and the extent of its support.  Conformance comes at this level, though sometimes features have lots of subordinate structure (paragraphs, for example, tables for another), and subordinate features are involved.  Clearly, operational scenarios depend on relevant features being supported, but that is higher level.  

Sometimes a feature characterization might be as simple as dealing with a single attribute and its basic variations.  There might also be edge cases to confirm, and discretionary cases as well (e.g., what range of arguments is a function defined for and what is the precision of the calculation for important subranges).

I mostly think of simple cases at this level, because they are easier to understand.  Maybe the best way to look at feature characterization is that supporting the feature might be relevant or even critical in an operational scenario (and in an application scenario above that) but that the feature is not a standalone thing.  Documents designed to confirm/expose/demonstrate/exercise just the feature and its support are contrived and not real-world.

4. FEATURE HARMONY CONFIRMATION

I am running out of steam (we are experiencing an all-time-record-since-recording-of-the-temperature hot spell in Seattle at this moment).  There are other cases which may really be about the specification as much as implementations.  The degree to which it is one or the other depends on how much latitude is allowed to implementations within the cover of the specification.  An example of feature harmony would be the use of table-cell:formula attributes on tables anywhere and even the use of formulas in other kinds of cells (e.g., for field values) that could refer to values in table cells and other named elements in a coherent way.  That is, how well can a graph in a presentation depend on cells in a table in the same presentation and possibly also in a spreadsheet sub-document?  

For examples of this kind, it will depend on whether the ODF specification actually leaves an opening for an approach that is perhaps beyond what is expected of implementations but is well-defined as far as the specification goes.

I'm sure there are cases of practical interest rather than the ones I made up on the spot here.  I can also see this coming up in places where there is something to be verified in avoiding inter-feature incoherence.  Something like having the manifest be in EBCDIC and content.xml being in SHIFT-JIS and the package content item names (such as "content.xml") being in ISO 646 (7-bit ASCII with bit8 = 0).  Although far-fetched, does the specification reject such cases and if not, does it provide enough to determine how this (and more-realistic cases) are expected to work in a heterogeneous interoperability situation.

I just wanted to distinguish in some qualitative way, operational scenarios, application (or usage or productivity) scenarios, and feature confirmation, even though they are not independent.  

I'm sure there is a better way to talk about feature harmony when features are used together in interdependent ways.  (The interdependency in my character-set encoding example is between the Zip content-item name, the manifest:full-path attribute value for that same item, and the use of no-scheme relative IRIs in the content.xml to refer to other content items in the package.)


 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org