Hello Jacques, Everyone,
Sorry for the delay on this. I have had a chance to review these
behaviors of multiple specifications with various spec leads within
Sun.
In this email, I wish to clarify some terminology and behavior, as well
as provide citations for Java Specifications illustrating this behavior.
Terminology
Umbrella Specification
A specification, which aggregates behavior through references to other
(component) specifications.
Component Specification
A specification that is referred to by another specification.
Behaviors
1.) An umbrella specification refers to a component specification
(wholesale, all assertions are directly inherited in the umbrella)
This happens very typically in Java Umbrella
specs.
Examples:
Java EE 5.0 spec
(http://www.jcp.org/aboutJava/communityprocess/final/jsr244/index.html)
Section 2.6 - Specifies inclusion of many component specs:
[HTTP, HTTPS, Java Transaction API, RMI-IIOP, Java IDL, JDBC,
Java Persistence API, Java Message Services, JavaMail, JavaBeans
Activation Framework, JAXP, EE Connector Architecture, Security
Services, Deployment Services, Web Services, Management Services]
Java Technology for Wireless Industry (JTWI) Spec
(http://jcp.org/aboutJava/communityprocess/final/jsr185/index.html)
Specifies inclusion of 5 component specs
Mobile Service Architecture (MSA) Spec
(http://jcp.org/aboutJava/communityprocess/final/jsr248/index.html)
Specifies inclusion of 18 component specs
2.) An umbrella specification refers to a component specification
(partially/conditionally, some assertions are directly inherited in the
umbrella, others with clarifications (additional requirements))
a.) In Java EE umbrella specifications, the spec may:
i.)Specifying requirement of an optional profile (subset of spec)
b.) in Java ME umbrella specifications, the spec has
i.) optional components that may become required
ii.) optional components that may be conditionally required (based
on hardware availability)
iii.) optional components that may remain purely optional.
Example:
Java EE 5.0 spec
(http://www.jcp.org/aboutJava/communityprocess/final/jsr244/index.html)
Section 4.3.2 - specifies mandatory implementation of an optional
part of a component spec:
"This specification requires all Java EE products to support
the javax.transaction.xa.XAResource interface, as specified in the
Connector specification."
3.) An umbrella specification refers to a component specification
with changes (some assertion's meanings are (slightly) changed within
the context of the umbrella)
a.) In Java EE umbrella specifications, clarifications
may be:
i.) Strengthening an Assertion (xxx MAY do yyy =>
xxx MUST do yyy)
b.) in Java ME umbrella specifications, a spec may
specify a component spec
i.) with additional requirements
Example:
Java Technology for Wireless Industry
(JTWI) Spec
(http://jcp.org/aboutJava/communityprocess/final/jsr185/index.html),
Section 3.3, the umbrella poses an additional requirement on the
measurement of current time:
"In a compliant device, the method
java.lang.System.currentTimeMillis() must record the elapsed time in
increments not to exceed 40 milliseconds."
These behaviors (observations) can probably be further generalized.
Perhaps Stephen can help us do this. Also, some spec leads here
suggested other possible behaviors linking umbrella specs to a range of
versions of a component spec (I'm starting to look at this now).
Hope this helps. Thanks,
Kevin L
Durand, Jacques R. wrote:
Kevin:
inline
Cheers,
Jacques
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
|