[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Comments on section 3.4 (multiple specifications)
Thats useful input. I like the term "umbrella
specification" , but I find "component specification" could be misleading. Could
be narrowly understood as covering a component of the Umbrella targets.
How about "referenced" spec, or "subsidiary" spec instead?
The three cases need be presented, even if
succinctly.
Some suggestion for a final proposal:
- be light on examples that are tight to specific specs
(Java, etc) and see if we can abstract these using the "widget" imaginary spec.
Ideally the guideline doc should be understood also by people outside the
software industry...
- concrete recommendations / best practices would be
useful, e.g. showing what are the various ways to handle these referencing
specs:
In case TAs exist for the component
spec:
o by using some blanket predicate asserting "conformance to
component spec" in the prerequisite element of TAs of the umbrella
spec.
o by selectively referencing appropriate TAs of
the component spec in the prerequisite element of Umbrella
TA.
o by selectively referencing a group of TAs (e.g. related
to a conformance profile) of the component spec in the
prerequisite element of Umbrella TA.
Finally, some statements in the umbrella spec just combine
with statements of the component spec on an equal footing (not using them as
prerequisites). That is the case of "binding"
normative statements that specify how to use both specs together, i.e. there are
TAs for stating that the binding is right, and the NormativeSource element of
such a TA is likely to refer to both specs.
Finally, there is the 3rd case below where some change is made to the
original statement. In taht case, it might be that a new TA has to be written
(and used as pre-req again). This problem is similar to Conformance Clauses that
also can change a SHOULD into a MUST, etc. Note that if the change is just the
presription level, and if the TA is used as prereq, that does not change the
meaning of the pre-req: regardless of the prescription level, the prerequisite
MUST evaluate to True for the umbrella TA to be applicable.
Jacques
From: Kevin.T.Looney@Sun.COM [mailto:Kevin.T.Looney@Sun.COM] Sent: Wednesday, May 21, 2008 1:02 PM To: Durand, Jacques R.; tag@lists.oasis-open.org Subject: Re: [tag] Comments on section 3.4 (multiple specifications) 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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]