RE: [tag] RE: more detailed mark-up items

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

Stephen:

That's a rather weak argument...
So far the rationale of this <TestAssertionParts> is that it is shared (since under <shared>) by all Tas in this set - or rather, it provides the (same) defaults TA parts for ALL Tas of this set. Then it is hard to see how two  <TestAssertionParts> elements can apply to the same TA. They could conflict. At best they could be complementary (e.g. one specifies the implicit targets, the other the implicit prerequisite) but in that case why not merge them?

I believe there can only be one prescription level per TA: in case the TA has several normative sources that themselves use different keywords (MUST, SHOULD...) I believe we said that the resulting prescription level is the "strongest" requirement level, e.g. "mandatory" if tehre is at least a MUST.

Was there any other possible semantics we discussed at F2F?

Jacques

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Monday, March 02, 2009 4:20 PM
To: TAG TC
Subject: Re: [tag] RE: more detailed mark-up items

For the question of Shared TA Parts and whether the TA Parts should be multiple occurance: One reason to make it multiple occurance (with additive logic) is that each occurance of the TA Parts could have its own Prescription Level (which does not apply to the other TA Parts).

Note: I think the structure used for the TA Parts should *not* be a reuse of the TA because the TA Id, I think, should not be included in TA Parts but it should be included in the TA.

- Steve

2009/3/2 Durand, Jacques R. <JDurand@us.fujitsu.com>:
> =========== current mark-up material:
>
> Schema and sample:
>
> http://www.oasis-open.org/apps/org/workgroup/tag/document.php?document
> _id=31406
>
> Current class diagram for our Test Assertions markup
>
> http://lists.oasis-open.org/archives/tag/200812/jpg00001.jpg
>
> =========== More detailed mark-up agenda:
>
>
> 1. Restating the context of use of the mark-up:
>
> - embedding TAs inside a document & embedding TA sets, vs. a specific 
> TA "doc"
> - kind of processing we expect on the mark-up? (overall objective)
>
> 2. Technical review:
>
> - The semantics of "multiples": how far should we go in specifying the 
> semantics of:
> o multiple TestAssertionParts elements in a TA set header.
> o multiple Predicate elements
> o multiple prerequisite elements
> o multiple Target elts.
>
> - Best Practices vs schema-supported:
> o individual TA referencing a TA group: define the way "tags" are used 
> for this?
> o prescription level: for "Property TAs": property used as a prefix? 
> (should we set it as @attribute?)
> - Details:
> o tag: Name = attribute?
> o handling of extensibility (anyAttribute, xsdAny...) what is the best 
> approach?
> o normative sources: case of "derived source": original source material vs.
> derived source that the TA will actually address?
> o in case of several targets, (should we provide means to identify a "main"
> target?)
>



--
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

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