Draft minutes Boston F2F, 4 Friday 2005 AM

Minutes for Boston F2F, Friday 4 March 2005, Morning
Scribe: Lynne

Attendees:
Tim, Patrick, Richard
Dom, Lynne, Mark, Karl

Guests:
Dave Marston


Discussion of SpecGL comments:  Issues 1144-1159

#1144: specification and workflow mixup
In Section 5 Quality Control, 5GP A, define an internal publication and 
review process is workflow oriented.  It is difficult to evaluate these 
workflow components, since it is different than the other 
guidelines.  Basically these are out of character with the rest of 
SpecGL.  Need to distinguish these better.  Proposal – move it, so it isn’t 
in the main body of the specification. This would be consistent with not 
mixing normative and informative information.  Rename good practice.  These 
aim at editing a specification. 2.3GP B systematic review of normative 
references rework so that it remains in the body of SpecGL.  GP Write test 
assertions should also be part of the spec. 5GP A, B is workflow. 5GP D, E 
could fit in chapter 3, if rewritten.  4.2GPA need for optional feature 
reword as use optional features as warranted.
Link 2.1B to 5C.
ACTION:  Move to appendix.  Reformat perhaps more textual, rename so there 
are no good practices.  Label as informative.   Karl
ACTION: rework GP2.3 B to be less workflow, but keep it in the main body of 
the document.  Dave 15 March
ACTION: Move 5GP D test assertions into chapter 3 and reword.  Patrick. 15 
March
ACTION: Move 5GP E formal languages into chapter 3 and reword.  Dom 15 March
ACTION: change title of 4.2GPA to Use optional features as warranted.
RESOLUTION: agree with the TAG, will separate the workflow aspects from the 
specifications aspects of the document.

#1145 conformance clause optionally is not reflected in proforma 
conformance claim
Would like to see a conformance claim proform for how to declare that you 
don’t have a conformance clause.  Suggested text is provided.
RESOLUTION: agree with the TAG and will adopt the example provided.

#1150 extensions and conformance interferences assumptions are limited
Implementers are not the only one creating extensions.  Need to express 
this.  Replace implementers with extension creators.

ACTION: reword Warn implementers not to create extensions… to Warn 
extension creators not to create extensions…
ACTION: add paragraph in 4.3 introduction about various types of extension 
creators – Dom  15 March
RESOLUTION: agree with the TAG and will make appropriate changes to the text.

#1154 error processing for non language or protocol specs.
What do you do if you are defining an API – where you would define an error 
mechanism, or other types of specifications? Suggest putting in a general 
statement like, For each class of product that is affected by an error 
condition, address how the error is handled.  Then provide examples, 
recasting current text for protocols/languages as examples and include API 
example.
ACTION:  Reword text and include examples  Dom 15 March
RESOLUTION: agree with the TAG and will make appropriate changes to the text

#1155 Use your own example
Section 5 Story – identify the group, QAWG.
RESOLUTION:  agree with the TAG.  We won’t be so modest and will come out 
of the closet.

#1157 ICS needs more than y/n/na
EncourageWG to link to the appropriate part of the specification that 
demonstrates each claim of conformance.  Add a Comments column.
ACTION: Part of  #1041, being addressed by Lynne
RESOLUTION: agree with the TAG, making appropriate changes to the text

#1158 ICS for SpecGL
Check that if we resolve all TAG comments we will answer Yes to all items 
in ICS.
1)      Not clear that SpecGL requires a completed ICS in order to claim 
conformance to SpecGL.  In Conformance Claim section, add bullet to 
‘include a completed ICS; Add to the example reference to the ICS – e.g., 
An ICS proforma is at <give URI>.  Clarify the ‘you can claim conformance’ 
that this is one example of what the claim can look like it.  Need to move 
SpecGL’s ICS from informative to normative.  Reword, in Conformance 
Criteria section last sentence to: If all the Requirements are checked as 
being satisfied, then conformance can be claimed as below. Converse is 
handled by statement that,  To conform to this SpecGL, all Requirements 
must be implemented.
2)      Keep definition of specification in the Scope.  Add definition to 
Glossary.
What is SpecGL’s COP?  Technical Reports with strong focus on specifications.
3)      Not different.
4)      Changed Conformance Clause is simple to Conformance Model of the 
SpecGL is simple.
5)      Discussed earlier, under workflow mix.
6)      Make more explicit - State that no subdivision is warranted. Add 
positive statement regarding explaining why not.  We want to encourage 
people not to subdivide unless necessary, this seems to counter 
that.  Status quo is that you don’t subdivide.  In 4.1 GP A add ‘only when 
warranted.  Talk about cost of subdividing in the What does this mean.
7)      No extensibility mechanism is presented, although we allow it. Fine 
for others to add new requirements (functions) REJECT this.
8)      Error handling – not applicable for SpecGL.  Need to reflect that 
this is not applicable to WGAC, SpecGL, etc.
9)      No obsolete features.  Need to mention that SpecGL has no 
deprecation, obsolete, etc. in its conformance clause.
10)  Internal process for review – addressed earlier by earlier TAG comment
11)  Addressed by earlier TAG comment
ACTION: make above changes.
RESOLUTION agree with the TAG, except as Noted (7). Have reviewed ICS and 
taken appropriate actions (e.g., modified SpecGL) to ensure that all items 
result in Yes.

#1159 Warn against untested hooks
Seems to be a process/workflow issue.  Under reviewing and testing, can 
mention putting in untested hooks.  Add RDF story provided.
ACTION:  Add as technique in 5 GP B
RESOLUTION: Agreed.

Tim report on CSS WG discussions on QA
-- CSS3 is a collection of many functions.  These functions are grouped 
into modules.  Modules can stand on their own. A module should be able to 
conform to SpecGL, as should a Profile.
-- COP for CSS3 triggered discussion as to whether authoring tools and 
validators were within scope and to be considered a COP -no decision made.
-- Rules to define profiles in CSS3 – none have been contemplated, since 
they don’t think there are rules or haven’t thought about this 
before.  Informally there are rules, since the dependencies need to be 
identified and consistent with the dependency graphs.
-- How does CSS validator know that the stylesheet has been written for a 
particular profile – user needs to tell the validator which 
profile.  Discussion, but no resolution.
Questions provided by Karl stimulated good discussion in CSS WG

WCAG Issues – quick review
Dom presents overview of WCAG

#1082 Extensibility of WCAG
Question as to whether a guideline can be extended – can WCAG success 
criteria be extended.  The guidelines are deliberately generic so that they 
can be applied and adapted (extended) by different policy makers.  Maybe 
want to indicate that it is O.K. to add additional guidelines/criteria, but 
do it in the style of the ones here.   Yes, extensibility is appropriate 
and define the mechanism formally.

#1083 Deprecation WCAG 1.0/2.0
Documents are very different and mapping between the two is neither easy 
nor direct.  One possibility is to declare 2.0 as a new document and not a 
revision of 1.0.  This avoids the issue.  Think this mapping may be 
difficult but important that people know the evolution of a feature. 
Suggest there be an appendix with the mapping, showing and explaining the 
evolution.  Use whatever format works.

#1090 Managing variability
  Agree with their discussion.

Received on Friday, 4 March 2005 17:06:40 UTC