RE: [oic] Discussion: Kinds of Features

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

I was looking for something else and found this useful post from Rob Weir over on ODF Adoption:

<http://lists.oasis-open.org/archives/odf-adoption/200907/msg00003.html>

There Rob refers to features as "end-user facing capabilities."  

1. I like the idea of end-user facing features.

2. On the other hand, I was thinking of features of the document at the ODF Document level.  I realize these are not the same.  That is, I was thinking pretty deep down in regard to markup features.  But my examples don't hold to that low level [;<).

3. I think the only features we can think of as end-user facing might be those that have some sort of document model (not DOM, just the abstract document model, not a programming or manipulation model) existence.  Tables are good examples of that, paragraphs might be.  (I say this because we really can't say much about UI at the level of ODF specification, although we can say quite a bit about presentation.)

4. I'm not sure how fonts and styles sort out because the abstraction probably collapses all of that to where it has effect, rather than dealing with the nuances of the document structure.  (But document-structure features matter.) 

5. With regard to presentation (e.g., on some presentation surface) there is a fair amount to be said about features that correspond to presentable elements (pages, headers, footers, text runs, graphics, etc.)

6. With regard to interaction-oriented elements (fields, event-based-actions, behavior selections such as running an animation, transitioning elements in a presentation view, etc.) there might be more to be said although that is pretty far away from anything that is well-specified in ODF.

7. I can see behavioral/dynamic features as well as interactive ones, where it is the (hosted) document that is thought to be what the interaction is with (as opposed to the host software product itself).

I'll stop here.  I think some of these other distinctions around features may tie to a more-or-less hierarchical view that was in another message from Rob Weir and I will have to find it.

 - Dennis



-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
<http://lists.oasis-open.org/archives/oic/200907/msg00032.html>
Sent: Wednesday, July 29, 2009 16:24
To: OIC TC List
Cc: Stephen Peront
Subject: [oic] Discussion: Types of Scenarios

[ ... ]

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.

[ ... ]