Re: [tag] Another proposal for 'shared' ta parts

[Stephen Green <stephen.green@documentengineeringservices.com>]

I guess a norm source could go out of date and
a new one in a new wrapping TA set could
override it. Maybe there are occassions it could
be composed too. OK.

Then same applies to interpretation.

Still not sure about comment though. Maybe the
comment could be to say that the testing is not
feasible with current resources but then a future
change in testing technology allows it so it is
overridden by a later wrapping comment.

OK. I'll do another iteration. Which values each
part gets for its conflict attribute might need more
thought and debate though - I can always hopefully
change them again if need be.

Best regards
---
Stephen D Green




2009/11/7 Stephen Green <stephen.green@documentengineeringservices.com>:
> OK, Jacques, but what about 'normativeSource', 'comment' and
> 'interpretation'? Do they 'deserve' a 'conflict' attribute?
>
> Best regards
> ---
> Stephen D Green
2009/11/7 Jacques R. Durand <JDurand@us.fujitsu.com>:
> Stephen:
>
> That looks much better to me.
> Some comments inline:
>
>
> -jacques
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com
> ] On Behalf Of Stephen Green
> Sent: Friday, November 06, 2009 12:05 PM
> To: TAG TC
> Subject: [tag] Another proposal for 'shared' ta parts
>
> Here's what I've found I can define in the schema, in line with Jacques'
> original proposal, I think:
>
> 1. Scrap 'overrides'
> 2. Scrap 'compositions'
>
> 3. 'shared' contains all of the TA parts
>
> 4. all except 'prerequisite', 'predicate' and 'prescription' simply obey a
> default (for most they compose, and 'var' is a declaration with TA Set
> scope)
>
> <JD> Not sure if we can say that they "compose" by default. E.g. shared
> <target> may either override the individual TA <target> or be overridden.
> They should all have a @conflict I think. But the default (when @conflict is
> not there), could be that the individual TA element if present overrides the
> shared. The benefit of making the TA "authoritative" is it is not confusing
> to readers, when inside a TA set the shared is apparently conflicting
> without any more indication.
>
> Now, some form of quantitative composition may occur when the cardinality of
> the element is [1..n], i.e. the shared items just add-up to the list inside
> the TA? (e.g. for variables?). Even so, we could have a variable name
> conflict... (so need @conflict on variable as well - and the expected
> default is like in programming lges: the "global / shared" is overridden by
> the "local")
>
> 5. 'prerequisite', 'predicate' and 'prescription' have a 'conflict'
> attribute
>      with controlled code values
>
> 6. the values are any or all of the following
> 'overriding'||'overridden'||'conjunction'
>      ||'disjunction'  but 'prescription' might allow one subset of these
> wheras
>      'predicate' might allow all of these, say
>
> 7. the values can be extended (if you put 'ext:...' as a prefix to the
> extension value)
>     and an implementation is allowed to ignore the extensions which it
> doesn't
>     'understand'
>
> Example (perhaps not a good one)
>
> <testAssertionSet>
> ...
> <shared>
> ...
>         <target>widget</target>
> ...
>         <prerequisite conflict="overriding" lg="en-us">has a button on
> top</prerequisite>
>         <predicate conflict="disjunction" lg="en-us">has a red button on
> top</predicate>
>         <prescription conflict="overridden"
> level="optional">overridden by mandatory TAs in set</prescription> ...
> </shared>
> ...
> <testAssertion>
> ...
> </testAssertion>
> ...
> </testAssertionSet>
>
> 8. predicates presumably need all four values; prerequisites just
> 'conjunction' and
>     'disjunction' and prescriptions just 'overridden' and 'overriding'
>
> <JD> It looks like ANY element that is not of logical meaning (i.e. not a
> prerequisite or a predicate) will need at least 'overridden' and
> 'overriding' as @conflict values, including <target>. We could decide that
> the default (e.g. for <target> in your example) is "overridden", whcih would
> give the advantage of allowing "exceptions" inside the set.
>
> 9. some future implementers might want to have prescription which can
>     'override' the existing level with an extended 'ext:deprecated' level,
> say
>     using the old TA in a TA Set with this deprecating 'prescription'
> in 'shared'
>
> Best regards
> ---
> Stephen D Green
>
> ---------------------------------------------------------------------
> 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
>
>