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

["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