Re: [tag] Conformance Clause update suggested

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

I kind of agree that ignoring most of section 4 with
regard to the conformance clause seems to fit
with the lack of normative language in this section.
I think the only normative terms are a 'may' in the
sub-section on TA Sets and a 'must' in the section
on outcome which is a repeat of what we now have
in section 3 anyway. The rest really is just best
practise or use case material and not really what
seems to me to be appropriate for conformance.
I'd be OK with leaving section 4 out of the clause.
Maybe a future version would have more weighty
material from which to distill normative statements.

Best regards
---
Stephen D Green




2009/11/10 Jacques R. Durand <JDurand@us.fujitsu.com>:
> Agree with your concern  - but I am not sure if we can extract clear "normative statements" from Section 4, which is mostly about best practices to handle challenging cases. Maybe the section on grouping (lists, tags) can be made easily normative.
> The easy way out, would be to simply ignore [most of] section 4 in the conf clause, meaning removing (a3) and (b4) from the conf clause.
>
> -jacques
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
> Sent: Tuesday, November 10, 2009 4:31 AM
> To: TAG TC List; Jacques R. Durand
> Subject: Re: [tag] Conformance Clause update suggested
>
> In (a).3 and (b).4 I'd be more comfortable with referring to 'normative statements' than to 'best practises'. (That way I think we'd be keeping in line with our own guidelines.) The concept that comes to mind for me when speaking of 'best practise' is one of non-normative practise that just happens to lead to a good outcome - it seems to me to actually *contrast* with the concept of a 'normative statement'. Normative seems to me to mean standard whereas 'best practise' suggests aspects within dimensions of variability which are found to work well but which can be changed if circumstances change in favour of better practises. I don't feel 'best practise' fits all that well with 'conformance'.
>
> Best regards
> ---
> Stephen D Green
>
>
>
>
> 2009/11/10 Dennis E. Hamilton <dennis.hamilton@acm.org>:
>> This is an interesting expansion of the discussion from the last meeting.
>>
>> It is also a good time to point out that there are specific guidelines
>> on the way conformance clauses and their targets are to be
>> characterized in an OASIS specification:
>> <http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines
>> .html>
>>
>> I find the Checklist in Section 6 to be particularly useful in
>> ensuring that the objectives of the guidelines are achieved.
>>
>> I also think we need to review the revised Technical Committee Process
>> sections 2.18 Specification Quality, just to make sure we are clear on
>> what is required.
>>
>>  - Dennis
>>
>> PS:
>>
>> -----Original Message-----
>> From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
>> Sent: Monday, November 09, 2009 19:27
>> To: TAG TC
>> Subject: [tag] Conformance Clause update suggested
>>
>> Bsed on previous comments:
>>
>> ----------------------------------------------------------------------
>> ------
>> ----------------------------
>> "Implementations subject to conformance are of two kinds :
>>
>> (a) representations of the test assertion model described in Section
>> 3, such as an XML mark-up schema and its semantics,
>>
>> (b) instances of test assertions, either using an informal notation as
>> done in examples, or using a formal representation mentioned in (a).
>>
>> NOTE: by extension, a processor or editor may also be considered as
>> conforming to this specification if it only produces conforming test
>> assertion instances (b) and (if applicable) if it implements a
>> representation (a) that is conforming.
>>
>> In order to conform to this guidelines, a test assertion
>> representation (a)
>> shall:
>>
>> (1) represent all mandatory parts and also the optional parts defined
>> in Section 3.1.
>> (2) use names for these parts that are identical or can be
>> unambiguously mapped to the definitions used in 3.1 as well as in section 5 (glossary).
>> (3) When supporting advanced features defined in section 4, i.e. any
>> of the
>> following: complex predicate, prerequisite, TA related to a property,
>> references to other TAs, references to external specifications,
>> inclusion of normative statements, versioning, variables, target
>> categories related to each other, then a conforming TA representation
>> shall use these features in accordance with the best practices defined for these.
>> (4) When supporting a representation of TA sets, the test assertion
>> representation must support at least one grouping mechanism described
>> in Section 4.6.
>>
>> In order to conform to this guidelines, a test assertion instance (b) shall:
>>
>> (1) contain all mandatory parts defined in Section 3.1.
>> (2) use names for these parts that are identical or can be
>> unambiguously mapped to the definitions used in 3.1 as well as in section 5 (glossary).
>> (3) when using optional parts defined in section 3.1, use names that
>> are identical to or can be unambiguously mapped to these definitions .
>> (4) When using advanced features defined in section 4, i.e. any of the
>> following: complex predicate, prerequisite, TA related to a property,
>> references to other TAs, references to external specifications,
>> inclusion of normative statements, versioning, variables, target
>> categories related to each other, then a conforming TA instance shall
>> use these features in accordance with the best practices defined for these."
>>
>>
>> -jacques
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>