tag message

Subject: Comments to Jacques notes on Multiple Specs (section 3.5.2)

From: Kevin Looney <Kevin.T.Looney@Sun.COM>
To: tag@lists.oasis-open.org
Date: Wed, 23 Jul 2008 11:52:51 -0700

Hi Everyone,

Stephen,/Jacques - I have reviewed this section with Jacques' comments.
Hopefully this can drive our discussion at the F2F.

For me, the editing the Target from my original examples to being the "Widget" (not the Widget Spec) is acceptable.

Further discussion should happen about moving the type of 'composition' (of the referenced spec) from the Prescription into a PreRequisite. (notes below).

Thanks, Regards,
Kevin

1.) Update Example 1 [from Jacques] (Wholesale inclusion):

TA id: widget-TA5

Target: Widget

Normative Source: specification requirement 112 in WidgetSpec 1.0

Prerequisite: [the widget] is conformant to WidgetMobile Small Screen Specification 1.2.

Predicate: [the widget] uses 3v DC input.

Prescription Level: mandatory

There are a few changes Jacques made to my original example:
1.) Target: Widget Spec => Widget [Kevin: This is OK]
2.) [the widget] is conformant to WidgetMobile Small Screen Specification 1.2. (moved from predicate to prerequisite)
[Kevin: I'm a bit confused about this - In my original example, this was a statement of behavior. In Jacques example, it is more like a conformance statement (and there is a new predicate stating a (different) specific behavior (guess - specified in "WidgetMobile Small Screen Specification 1.2)]

My original intent was to have a single statement of inclusion/conformance for a 'referenced spec'. In your example update, I feel that you are individually calling out specific behaviors from the referenced spec (ie. requiring that all such referenced behavior be called-out in the umbrella).

2.)   Conditional or Partial inclusion:

[Jacques] Along same line as previous one, using enhanced prerequisites:

      TA id: widget-TA5

      Target: Widget

      Normative Source: specification requirement 112 in WidgetSpec 1.0

      Prerequisite: IF [the widget] has hardware restriction of screen size 760 x 480 or less THEN [the widget] is conformant to the "small screen" COnformance Profile of the WidgetMobile Small Screen Specification 1.2.

      Predicate: [the widget] uses 3v DC input.

      Prescription Level: mandatory

[Kevin] I still have my concern of "moving" the "referenced spec" relationship (as a predicate) into a Prerequisite, this forces that individual TAs from the referenced specification to be individually specified in the Umbrella.    In my previous example, the "conditionality" was reflected in the Prescription level and the spec relationship was the (general) behavior of the referenced spec (eg. including many behaviors, not just "the widget uses 3V DC input"):

Predicate: This specification is conformant to WidgetMobile Small Screen Specification 1.2 for widgets with screen size of 760 x 480 or less.

Prescription Level: required (based on presence of hardware), otherwise optional.

Otherwise, I am (again) fine with changing the Target to being the widget.

[Jacques]

We assume here that the subset of requirements in the WidgetMobile Small Screen Specification that apply to screen size 760 x 480 or less is addressed by a conformance profile named "small screen".

[Kevin] OK

Here, the pre-requisite predicate is conditional so that conformance to the "small screen" profile is only required if the widget has restricted hardware, before applying the TA to this widget.

[Kevin] Again, I think this is not what I originally intended (eg. stating the relationships of the umbrella/reference spec) - I think this is trying to call out a specific behavior, and describe it in terms of a specific "configuration" for which it applies.

3.) Inclusion with changes:

[Jacques] I feel the third case below can be addressed by referring to the right Conformance Profile for the referenced spec (which will take care of requiring the optional features). That case seems to be covered by previous case.

[Kevin] I guess I am not familiar with "Conformance Profile" - I see conformance profile referenced in a few other sections of this guideline, but I don't really see it called out as a definition or part of the TA. I think your point is that "For some configurations, there are some TA predicates that apply), for others there are different TA predicates.

I am arguing that "The same assertion" may have slightly modified behavior - where I think you are arguing that different behaviors are specified in different TAs (and those TAs either apply or don't apply to a particular configuration).

I'm really not sure what to say in response to that - At Sun, it is more manageable for us to keep the Same TA definition for some general behavior, even though their may be slight difference to the behavior for certain configurations.