There have been a couple of suggestions on IRC that the interface
design of wmllint should change. Specifically, it has been suggested
that:
(1) WML files should be version-stamped, and/or
(2) wmllint transformations should be explicitly invoked by
command-line switches.
I will now explain why
Due to my typing difficulty ATM, I can't respond as verbosely as I'd like,
but I do want to weigh in on the shape of WML evolution, since it is an area
of great interest and concern.
>There are still good use cases for version numbering. Sometimes it's
>not possible to use a strategy like PNG's
Patrick Parker <[EMAIL PROTECTED]>:
> Not quite true... radius upconversion, for example violates NTC.
Aarggh. The one transformation I didn't write.
Please fix the transformation to have NTC. Otherwise I'll have to make
wmllint throw a warning every time it's done, or (see below) disable
it ent
> > >2. We have to be equally careful about reusing WML tag names with
> > >different enclosed or enclosing tags.
> >
> > too restrictive IMO
>
>Not too restrictive, in *my* opinion. We could go down a long rathole
>about this, but it's essentially a value and priority judgment. So
>I'm not goin
Patrick Parker <[EMAIL PROTECTED]>:
> While I'm perfectly capable of maintaining wmllint, I'd rather not start
> adding to my responsibilities. Honestly, I'm surprised you would resort to
> such an ultimatum / threat considering it was your foresight to hedge for
> this likelihood in the first p
Fair enough then. If you don't want to discuss things, I'll just consider it
an uneasy truce until you attempt to adjust or restrict WML in a way that I
cannot accept.
BTW, I think radius upconversion does not cause any cyclical changes, so it
may not violate your test. However, some valid 1.3.
