Skip to Content.
Sympa Menu

wikiworld - Re: [Wiki World] meta parser [was Wiki engine developers contacted]

wikiworld AT lists.ibiblio.org

Subject: WikiWorld

List archive

Chronological Thread  
  • From: "Milos Rancic" <millosh AT gmail.com>
  • To: WikiWorld <wikiworld AT lists.ibiblio.org>
  • Subject: Re: [Wiki World] meta parser [was Wiki engine developers contacted]
  • Date: Thu, 6 Sep 2007 12:46:48 +0200

On 9/6/07, adam hyde <adam AT flossmanuals.net> wrote:
>
> Well...I hope this is the right place for this conversation as I find
> its interesting. If this shoudl eb held off-list please let me know as I
> am new to this list...

Actually, I still don't know is it the right place for such
discussion. Maybe we should move such discussions through some time to
the wiki-research list
(http://www.wikisym.org/mailman/listinfo/wiki-research). But, it is
good to talk :)

As I said, I am thinking a lot last days about this issue. Actually, I
started to think about it when I wrote my last article about the
possible global future trends related to the wiki technology
(http://millosh.wordpress.com/2007/08/31/contribution-to-the-future-of-the-wiki/).

There are two things which are missing here.

The first one may be relatively easy solved with WYSIWYG editor and
HTML: I want to have a program (like a feed reader) to read and edit
all wikis (and something more) relevant to me. It is quite possible
that program is working using only HTML, even it would be a little bit
harder way.

But, the second thing is *really* missing. MediaWiki wiki syntax is
not only a markup language, but a fully programming language. By using
some extensions you are able to do 2+2 or even to make a for loop.
This is something which HTML is not able to do. And you are even not
able to make a spreadsheet in HTML (without JavaScript). And it is
possible to do the same in XML, actually, using XSLT. And maybe XSLT
is that "missing thing".

All of those issues may look like irrelevant to the WYSIWYG editing.
However, we need structured data because this is the only useful form
of data. OK, it is possible to search and then structure data, but it
is not reasonable (i.e., it is more expensive) when you are able to
structure it by default.

And there is one more issue: If someone want to make a for loop inside
of document, what should (s)he use then? XML/XSLT in which for
ordinary loop like "for a in range(1,1000)" there should be a list
from 1 to 1000? (I see only "for-each" in the syntax; not "for"; but,
maybe, it would be changed in the future.) Some visual syntax? (But,
even a spreadsheet programs has something like a "command line".) Or
some simplified syntax (and wiki syntax is a simplified syntax)?

At this stage, I see the next needs:

- Fully featured WYSIWYG editor.
- A complex, programmable wiki syntax (which would have shortcuts from
WYSIWYG editor).
- XML/XSLT storage generated and accessible per article (or XML or
HTML storage with some scripting language file per article if needed).

And if those are needs, then the major players should do the next:

- WikiCreole should define Parser functions inside of the syntax
(http://meta.wikimedia.org/wiki/Help:ParserFunctions).
- Wiki developers (including WikiCreole standardization) should define
wiki syntax in relation to XML/XSLT (or XML or HTML + scripting
language).
- Wiki engines should have APIs for standard queries. It should be
possible to say "give me structured data for that page now" (which
would give, for example, wiki or XML/XSLT or HTML+scripting language
code of the page, the whole page history; license data and the names
of the contributors and maybe even the talk page and its history [in
the case of MediaWiki and other wikis which support talk pages]).

Thanks to those features, it would be possible to do the next (using
some fictional program):

- User gets data from the wiki A.
- User thinks that it would be good to have that article on the wiki B.
- User copies the article.
- If, for example, license is not compatible, software would say that
it is not possible to copy a text because of incompatible licenses.
- If it is possible, program would import all important data to the
article on wiki B (including authorship and maybe even including the
whole article history).

There is a very complex set of possible features if such kind of
standardization would occur. For example, a complex and very usable
offline browsers would be possible. But, not only offline. It would be
possible to compare a number of articles from different sources and to
make the best choice in editing. And so on.




Archive powered by MHonArc 2.6.24.

Top of Page