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: [tag] Conformance Clause update suggested


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


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