Re: comments about some JM issues

About LC Issues:  84, 90, 85, 86, 87, 89, 97, 103, 105, 107.

Here is a processing plan for this batch.  I think we can Resolve all but 
2-3, and those need clarification.

At 05:42 PM 4/15/03 +0200, Dominique Hazaël-Massieux wrote:
>Le mar 15/04/2003 à 17:38, Lofton Henderson a écrit :
> > "Editorial" category...
> >
> > #84, #90:  I don't know what he means by "reflected in structure" and
> > "grouped structurally".  Is he saying, have a "DoV Guidelines" chapter and
> > an "Other Guidelines" chapter?  IMO, another level of structure adds
> > nothing.  [Oops, I see that these two are grouped in a series of "Related
> > DoV issues"]
>
>I'm not really sure what he means too, but I think I agree with him that
>moving the DoV section out of the introduction would be worthwhile...
>We could make the second section a section about dimensions of
>variability for instance.

It would be kind of a small section, but I don't feel strongly one way or 
the other.  However, by "grouped structurally" is he suggesting a chapter 
containing the DoV guidelines (2..9), and another chapter containing the 
others?  I'm not convinced that adds anything, but it doesn't bother me 
either.   Note. I think it will require some fixes to our XSLT formatting 
stylesheets.

By the way, I vaguely remember that we decided to delete the "Roadmap to 
Guidelines" section that preceded the current "1.8 DoV".  See

http://www.w3.org/TR/2002/WD-qaframe-spec-20021108/#roadmap

I think that was a mistake.  In particular, the two bullets at the end of 
"Roadmap..." added some useful orientation information and structural 
overview.  (Plus -- ed note -- "1.8 DoV" starts off badly now.)

Proposal:
1.) discuss to clarify the intent of #84, #90;
2.) if successful, decide now (or postpone till "Related DoV");
2.) restore some of "Roadmap.." and consider Dom's proposal to split DoV 
discussion into new Chapter 2.


> > #85:  "self-sufficient guidelines and checkpoints" -- it would be a huge
> > amount of work, and take a long time, IMO.
>
>Well, what he's asking is not do it completely, but to do it as much as
>possible... That's probably something we need to keep in mind, and even
>maybe to make a specific reading of the specGL through this view.

"...as much as possible" -- IMO, that is very little.  Our resources are 
stretched VERY thin, and I believe that we have to focus very much on only 
what is necessary to finish the GL (whatever "finish" means -- "Rec" or 
"Note" after next publication, or ...).  He says,

"Insofar as is possible guidelines and checkpoints should contain 
sufficient definition for local understanding, and pointers to all related 
items in the document. That is, a reader should be able to enter via any 
checkpoint, and gather all and only the information needed to understand 
the checkpoint starting from that entry point."

This is nice, but I'd guess it would be a couple-few days of someone's time 
to make a reading from this viewpoint, and markup every place where we need 
more prose, or links to other parts of the document, etc, and then to 
implement all those anchors and links.  Volunteer?

However, I accept that we ought to keep it in mind going forward, as a 
principle for new stuff or when we are already re-organizing a 
section.  For example, I think we should do a better job of linking terms 
to their (sec.4) definitions (WAI does this extensively -- every occurrence 
is linked to its definition.)  And retro-active application of such a 
limited scope would probably take less than a day of the editors' time.

Proposal:  "we will try to apply this principle better as we go forward 
with editing and revision".


> > #86:  "Spelling, grammar, and style" -- okay on spelling and grammar; the
> > "style" comment -- while I sympathize, on the other hand it is problematic
> > to get uniform style with a mix of authors.
>
>I have 2 issues with this:
>- he doesn't say where the errors are; I'm likely not to find them, so
>we probably need someone to make a quick pass through
>- regarding the style, I'm again not in a position to spot these changes
>of style easily; but I think it is not that important (it's in the "nice
>things to have" category)

Proposal:

1.) at the WG-only draft preceding next publication, have someone make a 
pass.  Would MS be interested to volunteer, as he has made a couple of 
complete end-to-end readings already, for SpecGL-by-SpecGL conformance scoring?

2.) I agree, if grammar and spelling are correct, that we might have to 
live with "jarring" style.


> > #87:  abbreviations -- again, I don't understand his comment (is 'bibloc'
> > something from xmlspec?)
>
>Yes, it is
>
> >.  I assume that he means the references like
> > "[SMIL20]", which indeed should refer to something in References.  Do we
> > have instances that do not?
>
>I have tried to make sure they do appear... Maybe he just means that
>they should be in [] also in the references section? I don't know...

Good catch.  I never noticed that.

Proposal: add [] in the References section; plus, SpecGL Issues Owner (LR) 
write to JM and ask if that's what he meant.


> > #89:  "move the glossary into 1.6" -- I have no strong feeling.  It is 
> done
> > both ways (e.g., WAI does it our way).  I slightly prefer our way.
>
>So do I...

Proposal:  "It is done both ways in W3C specs.  We prefer this way."  No 
change.

Proposal 2:  Change "1.6 Terminology" to "1.6 Usage of terminology in this 
document", and add a sentence to 2nd pgph, to the effect "When used in this 
specification, terms have the meanings assigned in 'Definitions' and 'QA 
Glossary'" (Which pre-empts one line of arguments, if the Defs/GLoss are 
non-normative, as we claim.)


> > In "Substantive" category, here are some comments/questions:
> >
> > #97:  "Modules as extension points"  -- I don't understand what he 
> means by
> > "point of extension" [This issue is grouped into the
> > profiles/modules/levels group]
>
>Well, in Web Services, you can swap a module for a new one, provided
>you've followed some rules in defining the new module. It is an
>extension mechanism, indeed.

Hmmm... you can swap a module of your own for one of the standardized 
modules?  And does your own module contain standard technical features, or 
extension functions of your own?  I don't know much about Web services.  It 
would be interesting to see a simple example explained.  Any case, it 
sounds different from "Rules for profiles".  It sounds like the

Proposal.  Deal with it under "Extensibility", "Prof/mod/lev", or 
whatever.  Try to get clearer explanation and/or examples from one of our 
WS-savvy members.


> > #103:  "Distributed conformance section OK" -- I think he misunderstands
> > the checkpoint (10.1), by his (incorrect) assertion that SpecGL
> > fails.  SpecGL has a conformance section, that is a single starting point
> > to find all other conformance provisions.  I suggest that 10.1 is too
> > terse, and needs a little bit of clarifying discussion.
>
>The culprit here is that we are using the term "conformance
>requirements" in 2 meanings:
>- the requirements you have to meet to be compliant with the spec (our
>"conformance requirements" labels)
>- the requirements that are derived from a given conformance policy
>I agree that this needs clarification.

Yes, 10.1 ConfReq says:  "document its conformance policy and specific 
conformance requirements in a dedicated section".  By "document ... 
specific" we did not mean "enumerate", which is how he is reading it.  The 
Rationale is a little clearer, that the conformance section is the starting 
point.

Proposal:  fix it.

> > #105:  Part of the comment is, "nor is it entirely clear that these
> > separate sections do not contradict one another."  This is an 
> unprocessable
> > comment (how do we prove "no contradiction", in the lack of any asserted
> > contradictions?).  Maybe it will go away if we do some consolidating of 
> GLs.
>
>Yeah, unclear...

Should we write to JM and invite him to point out specific 
contradictions?  Or resolve issue with reply that "we don't find any 
specific contradictions" (and maybe add something about the outcome of our 
consolidation considerations).

Proposal:  discuss briefly, decide between two above alternatives.


> > #107:  A[A[A]] priroities versus OpsGL table 1 -- we can make this go away
> > by agreeing that we will fix it in OpsGL, which definitely does set up a
> > parallel and in some places contradictory requirement.
>
>Yes... This table has caused way too much damage, we need to get rid of
>it...

Proposal:  fix OpsGL, reply accordingly.

Regards,
-Lofton.

Received on Wednesday, 16 April 2003 19:31:33 UTC