RE: [tag] Comments on section 3.4 (multiple specifications)

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Kevin:

inline

 

Cheers,

Jacques

---

From: Kevin.T.Looney@Sun.COM [mailto:Kevin.T.Looney@Sun.COM]
Sent: Wednesday, April 16, 2008 9:46 AM
To: TAG TC
Subject: [tag] Comments on section 3.4 (multiple specifications)

Hi Everyone,

    Stephen - I had an AI to comment on this section, but it was delayed while I was recovering.

    The placeholder text for this section (3.4) is sufficient, but terse.  I think there are a few main points that mostly need to be hilited:

1.) (primary) specifications may *reference* (component) specifications 

 

<JD> Maybe its worth relating to some real-world cases, possibly illustrating different forms of "referencing". In many cases (such as mentioned by K-TAG) the composition is of a layering of specs. This is overwhelmingly the case for "protocols"  (telecom,  networking, messaging). In other cases, this is more an "embedding", i.e. the implementations of two referencing-referenced specs have a component relationship: an impl of spec A contains a component that is an implementation of spec B. E.g. a MIME multi-part message is designed for embedding instances of XML docs, or other doc type.

In both cases, there are usually some "binding" requirements specifying how these specs integrate. That means we have to deal with 3 kinds of normative sources, not two:

- primary TAs (source: primary spec)

- binding TAs (source: binding requirements, often found in "Appendix N: binding with spec XYZ" )

- "referred" TAs. (source: component or underlying spec)

2.) References to (component) specifications may be complete (inheriting all TAs) or partial (inheriting a subset of TAs, possibly based on a logical condition).
3.) TAs inherited from a component specification may have a different meaning, based on the context (umbrella) where it is interpreted.  This may lead to modification of the TA, or modification of the implementation (test) extended from the TA

It would be good to give illustrations of each of these characteristics.  I can conjure up some examples - but our colleagues in the KTag showed interest in this topic before, - perhaps they might be able to provide 'real world' examples.

Here are some conjured examples:

1.) (primary) specifications may *reference* (component) specifications

    This specification (S#24355Widg) is the overriding description behavior of Widgets.  S#24355Widg includes specifications of (S#24340WidgEmb) widgets embedded in real-time devices, (S#24344WidgMob) Mobile widgets, and (S#24346WidgConst) widgets in constrained computing environments. 

 

<JD> these examples may not be best to illustrate our topic: Unlike the above cases of layering (where the test targets are really distinct) or of composition (where test targets are component of each other - still quite distinct in nature) the test targets are here subclass of each other. We could make the case that all these are actually different parts of a same spec.  (like the requirements for medium-size widgets are merely an extension to the requirements set for widgets.)

However, presented from another angle, the example you mention may actually be an interesting case of referencing specs, but the other way around !!! The embedded widget spec is the one referencing the widget spec, not the other way ! (because an embedded widget inherits from widget)

So you say:

>S#24355Widg includes specifications for S#24344WidgMob Mobile widgets

But we could make the case for the opposite: because a mobile widget is still always a widget, the requirements for mobile widget include the requirements for widget that are supposed to apply to all widgets. We could say the same of "medium-size widgets" which also include (inherit) all reqs for "widget". I have tried to illustrate this relationsship in the Target Classes subsection (3.5.1) proposal.

 

 2.) References to (component) specifications may be complete (inheriting all TAs) or partial (inheriting a subset of TAs, possibly based on a logical condition).

S#24355Widg includes specifications for S#24344WidgMob Mobile widgets, with the exception of behaviors specified for continuous connection environments.

3.) TAs inherited from a component specification may have a different meaning, based on the context (umbrella) where it is interpreted.  This may lead to modification of the TA, or modification of the implementation (test) extended from the TA

TA#45:  S#24344WidgMob Mobile widgets specifies that a phone-number look-up must take 3 seconds

This specification (S#24355Widg) includes specification of S#24344WidgMob.

S#24355Widg may be used on spacecraft, approaching the speed of light.

Due to non-constant properties of time as a body approaches the speed of light, TA#45 must be altered to a smaller time boundary (< 3 seconds) to operate correctly in this environment. 

 

<JD> there has to be a more down-to-earth example !! :-) My general opinion would be: even if we know there is some valid point to make in the guideline, if we can't get our hands on a good non controversial example, then let us not make that point (unless it is really trivial ) - I'd just wait for a good example in the next version of the guideline. We won't be criticized for not covering everything (this is a mere entry-level guideline doc, not a TA encyclopedia) , but we can be criticized for making statements that could be misinterpreted or seen as dubious or gratuitous.

[OK - this last example is extremely hypothetical!]


A few other complications from multiple specifications also came to mind:

4.) TAs that conflict

      It is possible that two specification may each contain a similar TA that conflicts the other.  When the specifications stand alone, these TAs do not pose a problem.  However, when the two specifications are joined in a primary specification, a behavioral conflict arises in the specification. 

     This situation would require the primary specification to resolve the conflict (either by discluding one of the behaviors, or modifying the meaning of one of the TAs to be compatible with the other.

5.) Modification of TAs ... to a point.

     Care must be taken when TAs in a referenced specification are modified (for inclusion in a primary specification).  At some particular amount of modification, the TA is fundamentally changed from it's original meaning (in the original specification).  At this point, the author of the primary specification should consider discluding the inherited TA, and creating a new TA within the context of the primary specification.

Hope this helps, Regards,
Kevin L

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php