Retrospect on PAC review item 1.1

[Robin Cover <robin@isogen.com>]

Re: PAC Review item 1 suggesting: "Identify what other
groups/committees..."

This item was unfortunately constituted as part 1 in a
3-part proposal, per my straw-vote comments
['1.1, 1.2, 1.3', on which I voted "disagree" for 1.2
and 1.3].

While this topic is now officially closed, I would like to submit
for the permanent public record some justification for
the notion [which was rejected].  These examples may prove
useful to others in case the question is reconsidered as part of
some future revision effort.  I would have referenced these
examples in the discussion of 2001-06-13 had I thought the
question was genuniely open for discussion.  The suggestion
was defeated, ostensibly, on the grounds that we cannot
"require" someone to know something.

Note that I have no interest in the logistics of
coordination; I am concerned only in providing information
which is legitimately of interest to the public, whether
this "information" is null or non-null.

My note of April 23, 2001 referenced both the NISO and JCP
as examples of workable implementation in normative
proposal documentation.  I will here illustrate the notion
by reference to its use in ISO, NISO, and JCP [Java
Community Process].  I would not be surpised to see similar
normative conventions in other standards process
technical work.

I. ISO [e.g., New Work Item]

The form for "Proposal for New Work Item" contains a
section labeled "Relevant documents to be considered."
This data item is apparently governed under rules for
"Justification of proposals for the establishment
of standards"; cf. ISO/IEC Directives, Part 1, 1995,
Amendment 1, "Procedures for the technical work,"
formerly ISO Guide 26:1981.  E.g.,
http://www.ansi.org/public/news/2001apr/DirectivesP1.pdf

For convenience, see a recent example in "Proposal for
a new work item"
http://xml.coverpages.org/ISO-WG1-0223.pdf
"Document Schema Definition Language (DSDL)"
referenced in
http://xml.coverpages.org/ni2001-06-12-b.html

Description: "Any known relevant documents (such
as standards and regulations) shall be listed,
regardless of their source. It would generally be
helpful if the list of documents could be accompanied
by an indication of their significance. When the
proposer considers that an existing well-established
document may be acceptable as a standard (with or
without amendments) this shall be indicated with
appropriate justification and a copy attached to
the proposal."

Comment: Note that the designers found wording which
avoided the (putative) epistemological crisis --
by using the word "known."  I have no idea whether
an NP which left this content null would be accepted,
but I assume so: if nothing is "known" and or
"relevant," then nothing is known/relevant: blank.

I see several advantages to using the labeled section (which
may be left blank).  Whether it's left blank or
filled in, the readership can make a judgment about
the proposal and the proposers: did they do their
homework?  are they trying to hide something? Should
I send them email alerting/reminding them that
similar design/specification work is underway in
XXXXX group?  As I said in my April 23 note: "At
a minimum, the list of 'related work' projects
could improve the quality of OASIS TC work if the
people proposing the new TC were genuinely unaware
of similar activity in another arena."

II.  NISO

NISO

Proposals have a notion of "Closely related standards
activities"

Description: "Closely related standards activities:
identify any existing NISO standards, international
standards, and standards developed by other groups
in the U.S. that are related or would be affected
by the proposed project. Would it be beneficial to
have a coordinating liaison with other professional
organizations or groups during the development of
the standard?"
http://www.niso.org/pdfs/OpProc.pdf

Comment: NISO members apparently don't regard this
language as oppressive, despite the omission of
a qualifier, no doubt understood, "...as far as may
be known to the proposers."


III.  JCP [Java Community Process]

By way of example:
http://www.jcp.org/jsr/detail/106.jsp
JSR-106 XML Digital Encryption APIs
and similarly illustrated [probably normative?]
in several Sun JSRs related to XML, listed in
http://xml.coverpages.org/ni2001-06-06-b.html

Document skeleton:

"Section 3: Contributions
   3.1 Please list any existing documents, specifications,
       or implementations that describe the
       technology. Please include links to the documents
       if they are publicly available.
   3.2 Explanation of how these items might be used
       as a starting point for the work."
       
Comment: This language may not capture in ideal terms
the notion of "related work," but in practice, the
authors of JSRs seem to get the idea.  I don't know
whether the proposers are required to say something other
than "Nothing known at this time".  The point of the
document subsection, in my thinking, is precisely to
force the submitters to say what they think is relevant.
No matter what they say (including nothing), it may be
very relevant to the public and the grounds for
understanding/evaluating the proposal.