Re: [tag] Reservations about basing 'testAssertion' and 'shared' on common type

[Stephen Green <stephengreenubl@gmail.com>]

We could have two sets of shared elements which could each be a subsection
of the TA Set header: one set called 'overrides' and the other called
'composites'
It might be different parts which are included in these containers, e.g.

<testAssertionSet>
 <header>
   <variable...
   <tag...
   <overrides>
     <target>...</target>
     <predicate>...</predicate>
   </overrides>
   <composites>
      <prerequisite>...</prereqisite>
   </composites>
 <header>
  ...

</testAssertionSet>

It might be feasile for some TA parts to appear in both 'overrides'
and 'composites'.

---
Stephen D Green




2009/8/27 Jacques R. Durand <JDurand@us.fujitsu.com>:
>  I have no strong opinion here...
> Also we have not yet resolved the "sharing modes":
> - some [shared] values are directly inherited by individual Tas, which
> may override them.
> - some [shared] values are directly inherited by individual Tas, which
> may only "add" to these in a form of composition, e.g. an individual
> Prerequisite element in a TA would not override, but compose (AND) with
> it.
> So we might have to add a @mode of sharing for each element of the
> <shared>, one more reason I see to keep <shared> defined differently in
> the schema ?
>
> Jacques
>
> -----Original Message-----
> From: Stephen Green [mailto:stephengreenubl@gmail.com]
> Sent: Monday, August 24, 2009 12:04 PM
> To: TAG TC
> Subject: [tag] Reservations about basing 'testAssertion' and 'shared' on
> common type
>
> I have some reservations about using a common type in the markup to make
> 'testAssertion' and 'shared' derive from the same type (at least for
> those elements they have in common).
> A major argument in favour of the common type is to reduce redundancy.
> The argument against it which concerns me is that this introduces a weak
> feature when W3C XML Schema derivation (extension) is used. It adds
> complexity and may be a cause for concern if we ever wanted to further
> extend the types in another version. In principle there is no problem
> with using extension; it's just a concern when this is done with W3C XML
> Schema (as in TAML version 0.3). My opinion is that if we continue to
> use W3C XML Schema to define TAML we are better trying to avoid
> derivation more than we try to avoid redundancy.
> ---
> 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
>
>