(Longish) Let's abstract a bit

[Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>]

There's been a lot of comments this past week regarding the new proposed changes to the Process document. I believe that there has also been a lot of confusion and misunderstandings related to the why and how of the proposed additions. One of the main culprits in this confusion has been, in my view, the fact that we are by necessity expressing ourselves using verbs and nouns that carry heavy connotations and ambiguities.

So if I may, let me abstract the language and the proposal a bit with a view to take perhaps more objective snapshot of where we are.

Imagine for a second that what we currently have is a bucket. The bucket is called Red. The bucket can move three squares to the left. The lid of the bucket has holes in it. The holes are of various shapes, circles, squares, ellipses, etc. Only objects whose shape corresponds to the shapes of the holes are supposed to go through those holes. The objects can be three-dimensional, and therefore possess mass, or they can be two-dimensional, and therefore be massless. The laws of gravity apply to all objects in this bucket, but of course only have an effect on those objects that have mass. So far so simple. However, the fly in the ointment is that because there is no one appointed to look at or into the bucket at all times, and because the holes themselves are two-dimensional, there is no telling whether a small circle got in through a circular hole or through a square-shaped one whose sides are larger than the diameter of that circle. Or perhaps it's a shallow cylinder that got sideways through a star shaped hole. On the other hand, there are a lot of objects out there that cannot fit comfortably in any of the holes in this bucket, no matter how much one tries.

So now we're thinking of adding a Blue bucket. This bucket can move two squares to the right. The lid of the bucket also has holes in it. There are many more holes than in the Red bucket's lid, but their shapes are limited: only straight lines define them. Only objects whose shape corresponds to the shapes of the holes are supposed to go through those holes. The objects are supposed to be two-dimensional. massless ones, but as in the case of the Red bucket, it is impossible to guard against objects going through holes they were not intended to go through: there is no mechanism to prevent a three dimensional sphere going through a square hole whose sides are larger than the sphere's diameter. So, as in the case of the Red bucket, the laws of gravity apply to all objects in this bucket but have an effect only on those that are three-dimensional (looking at the objects through the holes at the top makes it impossible to know whether they are two- or three-dimensional; only those who put them there would know).

So, at the risk of over-simplifying, the main difference between the two buckets, once you have eliminated all those "they are supposed to...but no one can guarantee", is that one bucket is called Red and can move three squares to the left, and the other bucket is called Blue, it can move two squares to the right, and has many more holes in its lid than the Red one. Another big difference between the buckets is the intentions that underlie each of them. The Red bucket is intended for a few large, three-dimensional objects. The Blue bucket is intended for countless small, two dimensional ones. But there is no mechanism to enforce those intentions into certainties.

Now comes the exercise for the reader: re-read the proposed new process, and wherever you see Standards Track read Red Bucket; Non-Standards Track is Blue Bucket. Replace Templates with Lid-Holes and Specification with Three-dimensional Object; similarly, a Note becomes a Two-dimensional Object. And in all cases the IPR Policy should be replaced by Laws of Gravity.

Now definition p reads: "Blue Bucket Work Product" is any work product produced by a TC that conforms to a Blue Bucket Lid-Hole."

Of course, like any metaphor, this one can go only so far and no more. But I think it's a good mental exercise. It makes you realize that the name you give your categories is not as important as it would appear (so whether you call them Standards Track or Red Bucket really does not impact their formal meaning). And once you think about it you may realize that things like conformance clauses could be the equivalent of Weight, and therefore apply only to three dimensional objects, since those are the only ones that can have mass and therefore weight under certain circumstances (i.e. when gravity applies to them). In other cases, I'm sure, taking this further would result in absurdities, so I'll leave it here.

But this is the main lesson I derive from the above: unless we (OASIS) hire at least one, if not two, more Staff, there is no way we can monitor what goes into any of the buckets; there is already quite a lot of template-less material in the only track we currently have; in spite of what Jon says I don't think some of that material should be considered a specification, let alone a Specification, just because it can be asserted that it specifies something. And there is certainly nothing today that would allow a TC to produce comfortably a 10-slide presentation or a webinar as part of its work product. But let's be realistic: OASIS cannot hire more people unless membership fees are raised to levels comparable to those of other organizations, a step that we certainly don't want to take. So we either punch a lot more holes into that bucket's lid (which of course we could, but then nothing other than common sense [in whose availability unfortunately we cannot rely] would prevent an FAQ from becoming an OASIS Standard), or we do this second bucket thing -- which, by the way, is NOT intended to encompass some second class citizenship, as someone has asserted; if it was, we wouldn't have spent two years working on it. So what this proposal does is set up two formal tracks, whose only formal difference is a procedural one; the different intentions for each of them should be readily apparent, but they are not readily enforceable. Trying to define what a specification is, or what a presentation is, is hopeless, just as trying to make sure that a a webinar is not the recorded equivalent of a specification is just about impossible, which is why some of us insist that the laws of gravity must apply to both buckets even if they don't affect all objects within those buckets.

I hope this is helpful.

-- 
Eduardo Gutentag        |    e-mail: eduardo.gutentag@Sun.COM
Technology Director     |    Phone:  +1 510 550 4616 (internal x31442)
Corporate Standards     |    Sun Microsystems Inc.       
             W3C AC Rep / W3C AB / OASIS BoD