RE: [Phpwiki-talk] Re: Wiki RFC Discussion

[electron <ele...@mg...>]

On Fri, 27 Feb 2004 14:41:48 +0100 Reini Urban <ru...@x-...> wrote:

> electron schrieb:
> >>This seems fine by me, a standard could benefit everyone well. Below =
are
>  >
> > Standard for whom? There is no common wiki standard yet. If people =
will=20
> > decide on a standard one could switch from engine to engine, and =
only=20
> > the wiki's with the best features will survive. That's far too =
liberal=20
> > for me. Most new engines nowadays only survive because of their =
"weird"=20
> > new syntax and their usebase hooked to that, and not because of =
their=20
> > features. I don't like concentration that much.
> >=20
> > Before we get too far off base, are you for or against the RFC? I'm
going to
> > guess we are both on the same page as for it, if not what should it =
be?
>=20
> I'm strongly against this RFC, because I see only completely new=20
> inventions for wiki syntax. If so, then please a least common=20
> denominator of the most used wikis.

You'd think that an RFC would cover the most common cases in current use
so there'd be more chance of adoption by existing projects (especially
since Microsoft isn't involved...) Kinda stupid to spec out new,
incompatible syntax when there's already substantial overlap between the
various implementations.

---

Rurban knows common syntax a lot better than I do. RFCs, request for
comments, need commenting on. Especially if you think it sucks. The =
worst
thing that can happen is it gets published as-is, and then you have =
users
claiming your software is non-standard, creating a mess you now have to
implement and support. Especially if Tiki wants to claim standard.

---

> And in a less stronger opinion I'm against standardization of wiki=20
> syntax also. we already so many different wiki formats, which reminds =
me=20
> on lisp in the 80'ies or scheme on the 90'ies. if a standard will come =

> the small ones will die, because the features will then be more=20
> important.

You say this as if it's a bad thing.

Here's my perspective as a user/admin of open code. Like commercial
code, sometimes projects wither and die. For a few months I worried that
phpwiki was no longer actively maintained or developed and I was very
concerned about extracting and converting the substantial amount of wiki
content that I have to another wiki.

The worst thing that can happen to a wiki maintainer is losing the
content; having the content 'trapped' in a proprietary format is
possibly worse than just having it deleted because you still hold out
some hope that you can get it back.

A well-written standard would be a good thing so content can easily
transferred from one wiki to another. Wiki authors can use whatever
bizarre syntax suits them, as long as they can import and export the
content in a standard format.

> this happened to lisp with a complicated standard and scheme=20
> not with a super simple standard. that's why we have 300 different=20
> scheme implementations and 5 in lisp. (and only 3 of them strict ansi)

Why do we *want* 300 different scheme implementations? Think of it like
SQL and the weakness of the SQL standard: do we really want to have to
write SQL-for-Oracle, SQL-for-Sybase, SQL-for-Postgres, SQL-for-MySQL,
etc., etc.? What a waste of effort!

> > The XML schema is only for exporting/storage, not meant to be seen =
by
the
> > end user or even what we store in our databases. (Unless one is =
really
nuts
> > and has a ton of drive space.) Only to be included for engine
portability.
>=20
> I know I know. Another overly bloated XML parsing class just to please =

> some standard.

...and people who value their content and don't want to risk it being
trapped in code that no longer meets their needs.

> And which will never be supported by the smaller wiki's, where you =
will
> need it.

That's what an open set of standards-based libraries are for. Nobody can
force a developer to use them but if the standard is sane and everyone
else is using them, there's strong pressure to do so otherwise the
project will be (justifiably) marginalized.

I haven't looked at the draft in detail so I can't comment on specifics
(looks like they're just coding up Tiki syntax as the One True Way. Bad
idea.) I will say that there's a definite benefit to users in having a
standard simple data interchange format.

-- Bob

---

Besides saying I agree, I feel it's a waste to spend time on coding
something that's already implemented. Extensibility is a good thing.

-Jtp