[Web-SIG] Specification process

[Luke Arno]

I am only suggesting that we table this for now.
Latter, we need to have process. I am all for these
goals. However, if we create a standardization
process, people will use it. Things will get heavy. If
we identify a nice opportunity to create compatibility,
like url vars or whatever we are calling it, count me
in. Grab the low hanging fruit and leave the ladders
at home for now.

Lets look at the concrete example: url vars. Those of
us implementing are willing to create compatibility.
Breaking that compatibility is extremely undesirable
by technical reality without any invented authority. I
think all 5 of your requirements are already being
met by natural means. If we come across a real case
that calls out for a process then I will be the first to
agree to adopt such a "necessary evil." Until then it
is just an "evil." ;)

I think we need articles, tutorials and improved docs
to help spread the understanding of what WSGI
component oriented development means. That is
the missing piece, IMHO, not formality. As we see in
REST vs. WS, the lack of formality can be quite nice.

Cheers,
- Luke

On 11/2/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Luke Arno wrote:
> >> The "authority" is that:
> >>
> >> 1) the spec won't change without good reason, so you can start
> >> implementing against it (once it is "approved")
> >> 2) it's useful in multiple contexts
> >> 3) having implemented either side, you can expect that maybe *someone*
> >> will care (either producing or consuming what you are looking for)
> >> 4) some eyes have been on it, and it's passed the sanity check (and
> >> hopefully better than just a sanity check)
> >> 5) someone won't implement something they think is the same, but isn't,
> >> because the spec documents the requirements sufficiently
> >>
> >> Going through the process is a marker for all these items.  And really
> >> that's the only important part, if someone is able to claim all these
> >> things then maybe that's the only process that is important.
> >
> > I agree that some repository of documents as
> > to what conventions exist to enhance interop
> > between wsgi components is highly valuable.
> > I would rather see those documents present
> > real information upon which developers can
> > decide what to do rationally than an appeal to
> > authority in order to influence conformity on a
> > sociological basis. Hence my "bah" :)
> >
> > A document should describe the convention
> > and its status in plain language and factual
> > terms. In this case, I think we should just state
> > that there is a general consensus and which
> > implementations do and will support that.
> > Validators are nice too.
> >
> > None of that requires formalization thus far.
>
> The list of features I give *is* important to me, and I think a lot of
> other people.  What process is required to get to that, I don't know --
> just stating these qualities may be sufficient.
>
> > Some statement on wsgi.org as to our desire
> > to create interoperable components and our
> > general commitment to not break our APIs
> > without good reason might be good. I hope that
> > goes without saying and if not I tend to think
> > that actions (should) speak louder than words.
> >
> > Do we want to draw up some kind of WSGI
> > community constitution while we are at it? ;) ;)
>
> Actually I think some of what Ben and I have chatted about on IRC does
> go in that direction.  "Constitution" is a bit much, of course -- one of
> the good parts of WSGI components is that if you don't like something
> you just don't use it, or you fork it, or whatever.  We don't need
> consensus.  *But* the result can be confusing for consumers of
> components.  So we've discussed setting up some basic standards for
> projects -- opt-in backward compatibility policies (which you'd only
> adopt when you felt a piece had become "stable"), some security
> policies, and maybe some indexing (which wsgi.org can do from a few
> directions).
>
>
> --
> Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
>