Opposition to the current push to Revise 29500 Parts 2 and 3

Rex Jaeschke rex at RexJaeschke.com
Fri Aug 26 21:01:00 CEST 2011


Dear fellow WG4 members,

Starting with the Face-to-Face (F2F) meeting in Tokyo in September 2010, WG4
has discussed on a regular basis the idea of revising Parts 2 and 3.
However, during all the time spent on this topic thus far, I have seen no
evidence that such a revision is marketplace relevant, which, supposedly, is
the point of standards work. Specifically, I have not heard any
marketplace-relevant consumer or producer say that without such a revision
their implementation will be disadvantaged. [As the liaison from Ecma TC45
and TC46, I represent some 15-20 consumers/producers of Part 2, and none of
those has asked me to request a revision.] As such, starting with the Busan
F2F meeting, I plan to object to any time being spent during WG4
meetings---both F2F and teleconference---on this topic except to deal with
written papers that attempt to justify such a revision. Specifically, I
believe that papers and discussions of the details of any technical proposal
that might go into a revision (rather than as a DR) are a waste of time
until the idea of a revision has been justified and adopted. In the
meantime, I have no objection to our working on DRs against these Parts,
provided the resolutions are implemented in a COR and/or AMD.

Let me make it perfectly clear that I am NOT opposed to revising these (or
indeed any) Parts provided a defensible approach is used. For such a topic
to get on a future meeting agenda, I believe it requires at least the
following:

1.	A detailed written paper be circulated to WG4 at least 30 days in
advance. [Talk is cheap, and email and collections of ad hoc notes on slides
don't require serious thought/planning nor do they contain sufficient
context for people outside the committee to review. They are no substitute
for a well-thought-through paper written over some weeks with reviewers
along the way before it gets circulated to the whole committee.]

2.	Before any major decisions are made, a reasonable time be given for
liaison organizations (such as Ecma TC45 and TC46) to review proposals and
to provide feedback. [Claiming to know what is best for the industry without
letting that industry's players digest and comment is dishonest and destined
to failure.]

3.	Major decisions be made only at F2F meetings, where typically more
members and NBs are present, and, hopefully, more participants have actually
prepared and are paying attention. [As those of you present at the Berlin
F2F will know, the rushed attempt to close 3 conformance-related DRs in the
closing 30 minutes of that meeting shows how even decisions made at a F2F
can go very wrong.]

At the start of the Busan meeting, when we deal with "Approval of the
Agenda", if the draft agenda contains an item regarding Revision of Part 2
or 3, or such an item is proposed, I will object to its inclusion unless the
requirements above have been met and/or agreed to. 

I have worked on IT-related standards for 27 years, and it has been my
experience that after a WG has spent 3 years on DR resolutions (as WG4 has
done) it is common practice for some members to want to be able to "do some
real work" by leaving their own mark on major or minor revisions. However, I
do not believe the primary business of a standards committee is to amend,
extend, or revise without proper justification and discipline. In the
meantime, it should maintain the existing specification and not make work
for itself just to keep some people busy. 

It may well be that WG4 is meeting too often and thus has too much time on
its hands. Rather than discussing whether we need to meet so often, some
people are looking at how to fill the time we have when we do meet. At the
most recent plenary, we agreed to cut back to 3 F2F meetings per year
starting in Feb 2012. Perhaps it's also time to reduce the frequency of
teleconferences. (Note that we started out with calls every 2 weeks, moved
to every 3 weeks, and now to every 4 weeks, without any visible reduction in
progress. And we don't always use up the time available on teleconferences
or F2F meetings.) As such, for the teleconference schedule following Busan,
I propose that, on average, we have teleconferences no more frequently than
every 5 weeks.

Until now, the convener has simply had revision items on the agenda, or
allowed them to be added, and then most often lead a discussion on them
himself. As there will not be unanimity in Busan on having a revision item
on the agenda, the question then becomes, "Just how does the convener
determine whether there is consensus to have such an item on the agenda?",
and Murata-san will need to address that. 

As best as I (as the liaison with 15-20 implementations) can tell, the
appropriate question to ask members is, "Do you believe that known problems
with Parts 2 and/or Part 3 can be fixed via DRs?" If so, there is no need
for any revision. If not, then the next question is, "Do you represent or
can you cite a marketplace-relevant implementation that believes a revision
is needed to correct Part 2 and/or Part 3?" If so, "Please submit a paper
containing those specific issues and the justification for a revision".
Otherwise, there is no need for any revision.

Note that we had a similar situation regarding discussions of revising Parts
1 and 4. If you look at the minutes from the Berlin F2F meeting, Item 5,
"Long-Term Organization of Parts 1 and 4", you will see for the first time
actual stated positions from NB delegations and/or individual experts. I
strongly believe we should do the same with the questions I proposed above
regarding Parts 2 and Part 3. Talk is cheap, but saying something in a
meeting and having it be recorded in the minutes for all time gets people
focused and is a much better indicator of real need and commitment.

There is no doubt in my mind that the absolutely wrong question to ask is,
"Who's in favor of revising Part X?" or, "I would like to revise Part X;
does anyone object?" We all have our wish lists, but we shouldn't confuse
those with the real world of developing and maintaining an implementation.
WG4 should not be a forum for academic exercises or wordsmithing for its own
sake. Yes, there is wording in 29500 that can be improved; however, I do not
believe a standards committee's job is to make a spec perfect. Also, I find
it instructive that Apple, which has implementations of 29500 on several
very popular platforms, has never participated in WG4 and has not submitted
any DRs, yet its people have been able to figure out what to do.

It is easy to say, "I don't like the way this spec is written. If I were
doing it ..."; however, that is not sufficient justification for a rewrite.
Specifically, while Murata-san has said repeatedly, "Part 2 doesn't look
like a real standard", who is to say what a "real" standard looks like. Not
only do standards from different Standards Development Organizations (SDOs)
vary in style, so too do standards between SCs and even within WGs in the
same SC. In any event, Ecma TC46 (OpenXPS) members see Part 2 as being VERY
familiar as it was written in a similar style by the same people who drafted
the initial XPS specification. So while changing the appearance of Part 2
might satisfy one person's taste, doing so may well alienate people at
numerous existing implementers. And for what benefit?

A more recent twist on the revision discussion has been the suggestion to
spin off Parts 2 and 3 as separate standards, presumably to allow the rest
of the world to "more easily" leverage on our work. Again I ask, "What
marketplace-relevant force is driving this?" Whether we spin these off or
not, they are still the same specs, they came from the same place, they are
forever associated (for better or worse) with the ECMA-376 Fast-Track
submission, and it makes sense for them to be maintained by SC 34/WG4. So,
unless I see a liaison statement/request from a serious potential customer
who simply loves what we do, but can't possibly live with pointing to
29500-2 or 29500-3 instead, I will object to such a split.

Rex Jaeschke







More information about the sc34wg4 mailing list