[conformance] Minutes of 15 Feb 2002, Telconference

[Lynne Rosenthal <lynne.rosenthal@nist.gov>]

Minutes of the Conformance TC:
Teleconference
Feb 15, 2002

Attendees:
Mark Skall
(skall@nist.gov)
Chair
Lynne Rosenthal
(lynne.rosenthal@nist.gov)
Scribe
Sandra Martinez
(sandra.martinez@nist.gov)
David Marston
(David_Marston@lotus.com)
representing XSLT Conformance TC

Future Meetings:

·       

Teleconf:  March 15, 2002 at 10:00 (ES)

Tentatively, April 19, 2002 at 10:00 (EST)

Action Items for Conformance Document

·       Mark and Lynne to review the use of ‘shall’ and ‘should’

·       

Lynne
to clean up section 8.1.1

·       

Lynne
to draft paragraph on discretionary items

Relevant documents:
Conformance
Requirements for
Specifications
document 
Issues
List

1.

      

Housekeeping
Welcome to all participating 
A voting members not present = Lofton, David S, Rik, Aidan
Approval of previous minutes (Dec meeting/teleconf)
Review and approval of the Agenda

2.

      

Liaison
Report

a)      W3C Quality Assurance Activity

The First Public Working
Drafts of
the
Framework Document:
Introduction and
Framework
Document: Process and Operational
Guidelines are
available for public comment.  Work on the other Framework
Documents, Specification Guidelines and Test Material Guidelines has been
initiated.  

3.

      

Conformance
Requirements Guideline.
The Conformance Requirements for Specifications document was sent to
OASIS TC chairs for comment on January 14, 2002.  An announcement of
the document and an invitation for public comments was in Dee Shur’s
OASIS Newsletter, January 28,2002.  No comments have been received.

Mark led the discussion on the document and issues. 
Section 8.1.1, Change title to Modularity.  Review and
clean-up/clarify text. 

Issue 1:  Capitalization of prescriptive words (SHALL, SHOULD,
etc).  It was agreed that Lynne with Mark’s assistance will modify
the document.  Dave suggested that if the document was an XML
document, one could use stylesheets, XSLT, etc,  to emphasis the
prescriptive words, call-out and list only requirements, etc.  Lynne
stated that currently the document would stay in its current format
(i.e., word and pdf), but if resources permit, the document would be
xml’ized prior to submission as an OASIS standard. 

Issue 2-4:  Deprecated features.  The discussion of these
issues overlapped.  Dave explained Issue 2 and thought it could be
combined with Issue 4.  Deprecated features could be included within
the Guideline as discretionary items and a specification would pick one
of a set of scenarios (issue 2/4 lists possible scenarios).  May not
want to say a lot about the details of deprecation and leave the
specifics of how to handle it and the conformance consequence up to the
specification developers.  Mark proposed that the Conformance TC
should specify how backwards compatibility is handled, especially for
interchange (file format) standards.  And, TCs could (with reason)
be exempt from this requirement.  This way, there is consistency and
a better chance for achieving interoperability, less chaos and confusion
on how its handled.  The discussion continued with the following
points.  Some specifications may not think backward compatibility
important and handle deprecated features differently.  What are the
reasons for not wanting backward compatibility? Possible examples: UDDI
or ebXML Registries only allow latest version, lightweight
profiles.   Different communities may need to handle this
differently  e.g., interchange standards, content standards,
APIs.   

Can we make a generic statement?  Possibly:  for specification
>1.0 the specification shall address upward compatibility and
enumerate the behavior and conformance consequences for deprecated
features.  It could also address the recognition (give an error,
flag it, warning) of deprecated features. 
 
The following new issues resulted from discussion:
New Issue:  Should the Conformance TC mandate how deprecated
features are handled?  New Issue: Is backward compatibility
important to all TCs? 
New Issue: Should backward compatibility be a requirement for all
TCs and stated as such in the Conformance Requirements Guideline. 
What are the pros/cons of backward compatibility? 

Much more discussion is needed on these issues.  The W3C QA Activity
is also discussion these issues and we should take into account their
discussion (which will take place on March 1 at their F2F). 

4.

      

Progression
of document
Lynne presented 3 choices for progression of the document to Committee
Specification

a)      declare it complete without any changes other than capitalization and formatting

b)

      

add
a paragraph on deprecated features in Section 8, requiring spec writers
to address and specify the behavior of deprecated features; then declare
the document finished and call for a vote 
c)

      

continue
processing the document until the issue on deprecated features is closed
and results incorporated into document

Discussion:  It is possible to do (b) and after review period call
for vote as committee specification, but don’t progress to OASIS
standard, until new document (v2.0) with deprecated features is complete.
We will proceed with (b) and determine at the March telconf how to
progress.  Prior to sending the revised version, the W3C QA
discussion on deprecation will be taken into consideration.  

5.

      

Next
Teleconference scheduled for March 15, 2002 at 10:00am (eastern). 

Meeting Adjourned at 11:15am