OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Proposal for 'shared' in a TA Set


i.e.


<shared>
        <normativeSource>
            <comment>comment2</comment>
            <interpretation>interpretation2</interpretation>
            <refSourceItem>refSourceItem2</refSourceItem>
            <refSourceItem>refSourceItem3</refSourceItem>
            <textSourceItem>textSourceItem2</textSourceItem>
            <textSourceItem>textSourceItem3</textSourceItem>
            <derivedSourceItem>derivedSourceItem2</derivedSourceItem>
            <derivedSourceItem>derivedSourceItem3</derivedSourceItem>
         </normativeSource>
        <target>target0</target>
        <predicate>predicate0</predicate>
        <prerequisite>prerequisite0</prerequisite>
        <prescription>prescription0</prescription>
        <comment>comment1</comment>
        <interpretation>interpretation1</interpretation>
        <var>var0</var>
        <var>var1</var>
        <tag>tag0</tag>
        <tag>tag1</tag>
</shared>



Best regards
---
Stephen D Green




2009/10/30 Stephen Green <stephen.green@documentengineeringservices.com>:
> I start with a premise that there is a single default intention
> regarding concurrency behaviour for each of the TA parts
> when it is shared across a TA Set.
>
>
> target:
> Several TAs in set would share the target
> What if they had NOT the same target at TA level but all TAs in the
> set had roughly the same target where some targets were sub-categories
> of a broader target and we wnated to show this by putting the less
> specific target in the 'shared' section but making some TA targets more
> specific by including the more specific target in the TA within the set?
> All this could be consistent, I think, with a shared target which composes
> (by conjunction) with targets of any TAs at individual TA level. If a TA
> target is 'A' (widget) at set level and some have a more specific 'A.a' at
> TA level (medium-sized widget) then it seems that in general there is
> composition with conjunction since in general 'A.a' = 'A' AND 'A.a'
>
> variable: makes sense if it always overrides (no sense having >1 value)
>
> prerequisite: always composes but maybe a disjunction is sometimes needed
> - is there another way to do that? Disjunction seems to be a change to semantics
> of a ta set though so I'd just as soon make it a default rule that it
> is a conjunction
>
> predicate: makes sense not to override. Usually expect it is overridden or
> there is no TA predicate when there is a TA set with shared predicate. Maybe
> composition with conjugate OK as a general rules
>
> prescription: expect might want to be able to use an override if there is
> a use case where a profile TA set overrides, say, optional TAs with
> mandatory prescription. This all seems a special case so default could
> be the a shared prescription is overridden by a TA one because it would
> not in the normal use of a TA set/shared to change the prescription of
> a contained TA.
>
>
> tag: makes sense that it usually composes with conjunction
>
> norm source: as for target
>
> comment: as for tag
>
> interpretation: as for comment/norm source
>
>
> target: compose
> var: overrides
> prerequisite: compose
> predicate: compose
> prescription: overridden?
> tag: compose
> norm source: compose
> comment: compose
> interpretation: compose
>
>
> compose: target, prerequisite, predicate, tag, norm source, comment,
> interpretation
> overrides: var
> overridden: prescription
>
> So it seems feasible that each part has a typical defaul control
> of co-occurrance because each has a typical expection when it
> is shared.
>
> This makes me suggest we could maybe just use 'shared' with
> each TA Part as a direct child and the defaults could be made rules
> to determine default behaviour in case of co-occurrance/concurrency.
>
> Then there remains a question of what to do about allowing non-default
> concurrency rules but one way to do this would be to defer this to
> profiles and leave the 'shared' element with an 'xs:any' for extensibility.
>
> So I would propose removing 'composites' and 'overrides' as child
> elements of 'shared' and add rules to the spec with the proviso that
> these can be supplemented or overridden in a conformance profile:
> They are default rules.
>
>
>
> Best regards
> ---
> Stephen D Green
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]