[pmwiki-users] How to support case in-sensitive Wiki page names

[Ben Wilson]

Please, don't allow spaces in page names or case insensitivity in the
core. I see this as a serious question of "why break what works?" The
current approach allows spaces in the pages courtesy of [[this link
approach]]. Finding the page from here is a fairly straight forward.
Also, the use off camel case in the title itself conveys the requisite
word breaks. Even trivial use helps people read what TamingOfTheShrew
says. At best, loosen the core to allow these changes in behavior via
recipes.

In (US common) law there are levels of scrutiny for when an appellate
court reviews state action against private interests. Among those are
the polar opposites of "rationally related," and "strict scrutiny." In
the "rationally related" context, the court reviews the decision in a
favorable light thinking "because the government has so much authority
and the impact on the individual is relatively slight, the government
wins if its action is related to its source of authority."

Conversely, strict scrutiny is triggered when the impact on the
individual interest is great, or when the Constitution conveys greater
authority on the individual. This is the case in religion and speech
cases. In that case, the government almost always loses--winning only
when the government can show that it has a compelling reason. An
example of this would be the compelling interest in curbing violence
which allows governments to control the time, place, or manner of
public protest. (Conversely, since there's no compelling interest in
the government curbing minority discontent at the majority, the
government can't quell that.)

I would relate spaces and case-insensitivity in the page names as a
clear case of strict scrutiny. There should be a compelling reason why
the core is modified to allow either. Just because it is sometimes
inconvenient to some is not compelling.

First, why does the current approach _not_ work? The typical case is
either when MacDonald is involved, or when we do not want the
titlespaced to read "Taming Of The Shrew." Both conditions are
manageable via the same function--one I gleaned from the Cookbook,
which made a certain K. MacDonald pleased when her name was properly
spaced on a wiki site I manage. Why do we need spaces?
TamingOfTheShrew is legible enough. As a link, it is merely a pointer
to the correct page and does not have to be _that_ legible so as to
require "Taming_Of_The_Shrew" or worse "Taming%20Of%20The%20Shrew."
The fact that spacing and casing can be managed via recipe supports a
better solution should be left to the recipes.

Also, the introduction of case insensitivity appears to breech the
third principle of the PmWiki philosophy: "[i]n general PmWiki
features are implemented in response to specific needs, rather than
because someone identifies something that 'might be useful'. (sic)"[1]
Introducing AuthUser was a specific need because of the growing
interest in managing users as individuals rather than purely by
password. And yet, it is not an active part of the core, but must be
explicitly introduced by the administrator. Where is the _need_ for
case insensitivity? Can that need not be satisfied by a recipe? Or, is
#3 a nod to those of us who prefer stability? If there is no need, at
least the core should allow a recipe to change the behavior. This is
akin to the government being allowed to manage the time, place and
manner of a demonstration to discourage violence.

The fact that the change is "non-trivial" should support stricter
scruitiny as well.

I've been chatting up the "Markdown" markup approach in a few of my
past emails. However, I would never think to ask it be introduced into
the core. PmWiki's flexible design allows me to implement this
approach via recipe without touching the core. This introduces a
substantial change to how PmWiki behaves as it affects 80 percent of
markup individuals would normally use.

Handling non-ASCII is more rationally related because there is a
growing interest in PmWiki among those for whom ASCII does not
adequately address their language. Also, this does not appear to
greatly impact those who use ASCII. However, this may be something
that can be cordoned off to support ISO via recipe by designating. The
need to reach those who _need_ ISO introduces a rational reason to
allow it into the core. However, if a recipe could solve the problem
as well, it may be better in the interests of preserving stability to
keep it there.

In either case, the core should be left unscathed but-for allowing the
impacted functions to be overridden, and then letting recipes fill the
gap. That is, set the functions as variables, as with the
AsSpacedFunction. [Now, if this were a case insensitive PmWiki, it
could also be an AssPacedFunction. As an admin, I would not like that
link passed around. Think about "FishItems!"]

If the call for the ISO recipe is great enough, make it a script as
was done with AuthUser. This allows it to be easily added on by those
needing ISO, but leaves things pat for non-ISO. Either set of
suggested changes: spaces in links, insensitivity, ISO support, should
be something that can be added on, not tightly integrated.

I left the last CMS-esque tool because they cared little for reverse
compatibility. I had been using the product for six months and had
written several modules to support a charity site. Then, they
radically changed the core, sort of like forcing all compasses to
point West instead of North and having the bottoms of all maps point
towards Seattle. I adjusted my modules with some pain. Within six
months, maps then pointed to Calcutta, water was colored green,
forests colored blue, and compasses pointed SSW. Mind you, that is a
comparison of the pain I experienced. And, these releases were within
the same major version (e.g. from 2.4 to 2.5, and in one case, from
2.5.1 to 2.5.2).

By contrast, PmWiki has been incredibly stable for me for nearly two
years. I started in July 2004. The change from 1 to 2 was a wee bit
painful, but there was a rational move to improve quality (rather than
arbitrary map-edge direction changing). The steady march to 2.0 stable
and then 2.1 stable showed that rational move was preserved, and
backwards compatibility maintained. I mean, look at the number of
recipes that have remained fairly stable over the past year. That is a
tribute to stability. The recipes I had written that needed changing
were based upon wrong thinking on my part.

That said, I know Pm typically follows the stricter side of scrutiny
and it has been his guideance that has kept PmWiki so stable. When
there's a call for what I deem a radical change, I always balk. I at
least hope that helps ensure continued stability.

PmWiki is visible now. I've seen it in several rags and am noticing it
being discussed in geek star chambers. I hope recognition helps
preserve PmWiki as it is. I'm not saying there is not room for
improvement, but (with appologies to Mr. Crisp) that insensitivity is
an improvement that should be made via recipe. If the core needs to be
made more flexible to support insensitivity (or ISO), I'm all for
that. Of course, it doesn't help that I don't mind being "sensitive."
:-)

Regards,
Ben Wilson

[1]: http://pmwiki.org/wiki/PmWiki/PmWikiPhilosophy

On 5/13/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Sat, May 13, 2006 at 04:17:31PM +0100, Crisp, Steve [UK] wrote:
> > Any takers on this one?  Perhaps I have to modify the core PmWiki code?
>
> Supporting case insensitive filenames under Unix indeed requires
> some (fairly substantial) modifications to the core -- it's decidedly
> non-trivial.
>
> There are also some changes that need to be made to be
> able to support non-ASCII characters in filenames, and since
> it's hard to do either of these in a backwards-compatible way,
> I've been hoping to take care of them together instead of
> separately.  (If we eliminate the need for backwards compatibility
> it's less difficult, but still non-trivial.)  I've also been
> looking at the possibility of allowing spaces in pagenames.
>
> At any rate, I don't know when such changes are likely to materialize,
> depends on my schedule.  If we can come up with a clean and efficient
> implementation and migration plan it could happen fairly quickly.
>
> Pm
>
>
> > > -----Original Message-----
> > > From: pmwiki-users-bounces at pmichaud.com [mailto:pmwiki-users-
> > > bounces at pmichaud.com] On Behalf Of Crisp, Steve [UK]
> > > Sent: 11 May 2006 18:55
> > > To: pmwiki-users at pmichaud.com
> > > Subject: [pmwiki-users] How to support case in-sensitive Wiki page
> > names
> > >
> > > All,
> > >
> > > Q: How does one support case in-sensitive Wiki page names on UNIX?
> > >
> > > Problem:  I have automatically converted a load of html files to Wiki
> > > pages.  All page names start with a Capital letter.  My wiki site has
> > > been developed under Windoze so various have been inconsistent when
> > > using wiki markup.  For example to reference a file called "Testfile"
> > we
> > > may have used:
> > >
> > > * [[Testfile]]
> > > * [[testFile]]
> > > * [[TestFile]]  (:comment politically correct version:)
> > > * [[Test File]] (:comment other combinations of above with space
> > also:)
> > >
> > > On Windoze all works great.  Now we have moved to a UNIX O/S, proper
> > > recognition is given to capitalisation.
> > >
> > > Does anyone have a 'simple' config extention to plug-in to PmWiki
> > making
> > > it case in-sensitive when looking up pages?  I read
> > > 'AlternateNamingScheme'.  Anything there I can use (I was a little
> > > confused)?
> > >
> > > My Config:
> > > * Latest PmWiki
> > > * Only Views and TitleDictIndex cookbook extensions
> > >
> > > Thanks in advance for any assistance,
> > > -Steve.
> > >
> > > _______________________________________________
> > > pmwiki-users mailing list
> > > pmwiki-users at pmichaud.com
> > > http://host.pmichaud.com/mailman/listinfo/pmwiki-users
> >
> > _______________________________________________
> > pmwiki-users mailing list
> > pmwiki-users at pmichaud.com
> > http://host.pmichaud.com/mailman/listinfo/pmwiki-users
> >
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://host.pmichaud.com/mailman/listinfo/pmwiki-users
>


-- 
Ben Wilson
" Mundus vult decipi, ergo decipiatur"