(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-46) was last changed on 05-Oct-2008 17:38 by 69.243.201.36  

This page was created on 04-Sep-2006 01:57 by 217.162.145.188

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 7 changed one line
I just edited wikiohana.net an realized how hard the current order of "link first, description last" is to read in wikitext:
Moved discussion about address/description order to [Talk.AlternateLinkSyntaxProposal].
At line 9 changed 7 lines
{{{
This Wisdom is taken from [[Ward Cunningham's]] [[http://www.c2.com/doc/wikisym/WikiSym2006.pdf|Presentation at the Wikisym 06]]
}}}
vs.
{{{
This Wisdom is taken from [[Ward Cunningham's]] [[Presentation at the Wikisym 06|http://www.c2.com/doc/wikisym/WikiSym2006.pdf]]
}}}
--------
== 27. April 2007
Hi.
Just a short question: Are InterWiki-Links, like {{{[[WikiCreole:Creole1.0]]}}}, mandatory for an implementation of the WikiCreole 0.6 specification?
Thanks in advance!\\
-- Martin Junghans
At line 17 changed one line
For people that read from left to right the last one is much better. Most or all of the western world I guess. What's the earth population percentage of people reading from right to left? I have no clue. Are the Chinese reading from right to left? hebrew does. Anyway...
To be honest, they haven't been discussed yet, so basically we don't know. On the other hand, [[ThereIsNoWrongWayToImplementCreole]], so nobody will kill you if you skip them -- at the worst, you get some users complaining that they miss it.
At line 19 changed one line
What about changing this? -> from [[link|descr]] to [[descr|link] in case left to right readers are the majority?
-- [[RadomirDopieralski]], 2007-Apr-28
At line 21 changed one line
--[Christoph] 6-Sep-2006
It's only mandatory if you have an implementation of InterWiki in your wiki. If you don't use InterWiki, you can safely ignore it.
At line 23 changed one line
I think we should have "nothing new" and therefore stick to the current convention.
-- [[ChuckSmith]], 2007-Apr-30
At line 25 changed one line
What about whitespace around the pipe when renaming links? I think it should not be allowed. Thus: {{{[[page|name]]}}} and not {{{[[page | name]]}}}, for all variants of links. What do you think?
== Mailto links
At line 27 changed one line
-- AlexSchroeder
I propose the usage of {{{mailto://test@example.com}}} (to be rendered in output as {{{mailto:test@example.com}}}) for email urls, even if this is not standards-friendly.
Any opinion about this? Is there a better place where to post this suggestion? Or should we postpone the discussion to the next Creole specification?
At line 29 changed 2 lines
I'll accept the pipe - however, I see less clear precedent for putting
the page title before the link text.
-- [[DanieleC.]], 2007-Jul-03
At line 32 changed one line
In general, 25 wikis on WikiMatrix support labeled links:
Why?
At line 34 changed 2 lines
||Page Title, Link Text ||Link Text, Page Title ||Both
| 16 | 8 | 1
-- [[YvesPiguet]], 2007-Jul-03
At line 37 changed 4 lines
Although I'll admit the bulk of the precedent (including both MediaWiki
and TWiki) use the page title followed by the link text, I think this at
least shows that there's a debate. (By the way, Confluence is among the
wikis that give link text followed by the page title.)
In [[WikiOnAStick]] there is no automatic URL decoration, so external URLs (with protocol) have to be specified using square brackets {{{[[protocol://uniformresourcelocator]]}}}; if we'd parse {{{[[mailto:test@example.com]]}}} as test@example.com, a page titled {{{mailto:something}}} would never get the internal wiki hyperlink. Using the double slashes also on mailto protocol would prevent this. This is our solution to our problem, I still have to understand if it has relevance in WikiCreole.
At line 42 changed one line
Again, I tend to favor the idea of using the syntax:
-- [[DanieleC.]], 2007-Jul-05
At line 44 changed one line
{{{ [[Text | Target Page]] }}}
------------
At line 46 changed 3 lines
I think it more closely imitates the intuitive thought process of a
link; the text links to the page, so the target of the link is secondary
information to the text of the link.
== Inner Page Anchors and Links
At line 50 removed one line
--[Eric Astor]
At line 52 changed one line
I use JSPWiki primarily at work and I tend to always want to put the link first (because I want to link to something) and then describe what it means. I also remember [Janne Jalkanen] saying that he would change that order if he had the chance now and at the time he was just blindly following [PhpWiki] syntax. In any case, twice as many engines use PageTitle, then Description, including [MediaWiki], so I still think we should stick to this order. Also, if for some reason you cut and paste in HTML, you can just ditch the extra stuff around it to make the link instead of also having to also change the order in the wiki syntax.
For inner page anchors, the following syntax is recommend:
At line 54 changed one line
--[Chuck Smith]
{{{ [[#1]] }}}
At line 56 changed 2 lines
I'm also used to do {{{ [ url | text ] }}}. Maybe it's a habit from html, or from the wiki engines I use most. Anyways, if you don't want to break your train of thought, the put the link text only, and then insert the links when you finish the article. I found this way the most comfortable. Or just use [local names|http://ln.taoriver.net/about.html].
-- [RadomirDopieralski], 2006-09-07
Suggested HTML:
At line 59 changed 9 lines
I also lik the desription first notation, because it's much easier to read and understand. You first get what it's about and then the technical details (url/page/etc.). I also what to submit another syntax based on this. Please use the symbol greater then (>) instead of the pipe. First because it makes the order clearer.
{{{
[[this description is linked to>this page]]
}}}
Second because it is easier to use links with description in tables (if supported) without having to escape the pipe, as it is necessary in some engines. I think it could also be easier to implement then.
{{{
|a table |with [[a link>to a page]] |and other |cells
}}}
It's also easier to read then.
{{{ <a name='1' /> }}}
At line 69 removed one line
-- [JörgGottschling], 2006-16-06
At line 71 changed one line
I'm against the introduction of such new markup.
For inner page links, the following syntax is recommended:
At line 73 changed one line
I also think that the wording "Links should not be allowed to contain a linebreak" should be changed. What's the benefit of not allowing it? I see a benefit in not requiring this feature, but forbidding this features is useless crippling. I'm not planning on removing this features from my implementation, for example.
{{{ [[#1|text]] }}}
At line 75 changed one line
-- AlexSchroeder
Suggested HTML:
At line 77 changed one line
Linebreak restriction removed from [Creole 0.3].
{{{ <a href='#1'>text</a> }}}
At line 79 changed one line
--[Chuck Smith]
Note: without optional link text, using the {{{#}}} results in an inner page anchor. However, when using the optional link text, using the {{{#}}} results in a link to an inner page anchor.
At line 81 changed one line
The spec should do the difference between an implicit and an explicit link instead of an internal and external one.
-- [[JohnCook]]
At line 83 changed one line
An implicit link is a fully compliant URI in the text as defined by [RFC3986|http://www.ietf.org/rfc/rfc3986.txt] - no non-RFC3986 schemes allowed. The URI must be complete - no relative-ref (see Appendix A of the RFC).
I'd prefer a clearer way to disambiguate anchors and links, so that links don't need text; e.g. {{{[[@Chater1]]}}} for anchor
and {{{[[#Chapter1]]}}} or {{{[[#Chapter1|Chapter 1]]}}} for link.The at character is used for labels in some assembly languages,
iirc, so it isn't new. It would also blend more cleanly with links between pages.
At line 85 changed 2 lines
Example:
By going to http://www.wikicreole.org, you will see[[...]
-- [[YvesPiguet]], 2007-Jul-17
At line 88 changed one line
(Should Creole eliminate implicit links altogether?)
------------
At line 90 changed one line
An explicit link is made of a destination and an optional description (or the other way around?) enclosed between two square brackets. These two parts are separated by a pipe character.
== Clarification of rendering of markup around links
At line 92 changed one line
The destination (target) can be the title of a page, an InterWiki link ([InterWiki standardization effort]), or a fully RFC3986-compliant URI-reference.
I don't see anywhere in the examples of how
At line 94 changed one line
The description part in a link could mean different things depending on the order:
{{{ //[[http://my.book.example/|My Book Title]]// }}}
At line 96 changed 3 lines
* {{{[[Hyperlinked Text|Target]]}}} i.e. [Hyperlink Text|target]
* {{{[[Target|Alternate Text]]}}} i.e. {{{<a href="Target"
title="Alternate Text">Target</a>}}}
should be rendered. The Perl Text::WikiCreole module renders it improperly, interpreting double-slash after the http: as closing the EM.
At line 100 changed one line
In my experience, the former would work pretty well with external links and the latter with internal ones.
(This wiki renders it properly as //[[http://my.book.example/|My Book Title]]//.)
At line 102 changed one line
So, my suggestion is this:
I think failing to render this is improper behavior, but it's not clear from spec that it is, especially since it's clear that markup inside the link should be rendered, and there are no examples of this in the [[Creole1.0TestCases|Test Cases]].
At line 104 changed 2 lines
{{{[[Hyperlinked Text|Target|Alternate Text]]}}} with the text and alternate text part optional. If there is a possible ambiguity, resolve it as {{{[[Text|Target]]}}}. Ex.:
{{{
Since this is such an obvious failure, it ought to be clearly stated and a test case. (Or is it clearly stated somewhere I have missed?)
At line 107 changed 2 lines
1. I have one existing wiki page called Foo.
[[Foo|Bar]] would generate <a href="Foo" title="Bar">Foo</a>
-- [[CarlCravens]], 2008-Mar-24
At line 110 changed 2 lines
2. I have one existing wiki page called Bar.
[[Foo|Bar]] would generate <a href="Bar">Foo</a>
Hello Carl,
thanks for the hint. I've added your example to the [[testcases]].
At line 113 changed 2 lines
3. I have two existing wiki pages: Foo and Bar.
[[Foo|Bar]] would generate <a href="Bar">Foo</a>
-- [[ChristophSauer]], 2008-Mrz-25 08:16 (CET)
At line 116 changed one line
}}}
FYI, that bug in Text::WikiCreole is fixed as of today.
At line 118 changed 80 lines
Note: The rendering could be completely different depending on the implementation. Alternate text could be presented like hyperlinked text if none is present...
In the first example, a problem arises when someone creates a page called "Bar" afterward... The rendering will change for the one in example 3.
Also, how would I say in Creole something like: {{{ <a href="Foo"
title="Bar">Foo</a> }}} if I have two existing wiki pages : Foo and Bar.
The easiest solution is to write empty parts: {{{[[|Foo|Bar]]}}}.
Another possible solution is to "escape" one part or the other with quotes ("") - or another markup - to explicitly define the text or alt text (don't like that one).
Finally, with the special syntax of InterWiki links and URIs, there should not be any ambiguity, only possible misleading from potentially mischievious users. Ex.:
{{{[[http://www.google.com|http://www.myphishingsite.com]]}}}
Just thinking aloud... Any ideas? Do I make sense?
-- [EricChartre], 2007-01-01
Oh! and BTW, if the URI are compliant to RFC3986, and internal/InterWiki links do not contain spaces, it would be possible to use a space as a delimiter instead of a pipe.
If a target does contain spaces, it must be enclosed between quotes.
-- [EricChartre], 2007-01-01
Should Creole accept IRIs
([RFC3987|http://www.ietf.org/rfc/rfc3986.txt]) instead of URIs?
-- [EricChartre], 2007-01-01
I don't want to bring you down, but:
* <a> tag has no "alt" attribute in HTML, http://www.w3.org/TR/html4/struct/links.html#edef-A, and never ever had, http://www.rfc-editor.org/rfc/rfc1866.txt
* the solution you prose seems to be pretty unpredictable in behavior
* the solution you propose is not compatible with any wiki out there
* what's wrong with the current solution? what exactly are you trying to fix?
* the regular expression for URLs exactly as they are defined in the RFCs is a little complicated, http://foad.org/~abigail/Perl/url2.html, and hardly usable, http://foad.org/~abigail/Perl/url3.html
-- RadomirDopieralski, 2006-01-02
Sorry Radomir. I made a couple of mistakes indeed and I could have been more concise and to the point (should not have put any rendering suggestions). Also, forget about that whole title/alternate text thing, that is not what I meant. I just want to make the order less relevant.
My points are:
* Explicit vs implicit links
* Implicit links are not showed in the Links page as they are on the Creole 0.3 page...
* Even if it breaks the "Extensible by omission" principle a little, should Creole standardize the different syntaxes of targets (especially for implicit links) so that nothing breaks when exchanging Wiki texts?
** Internal target
** InterWiki target
** URI (RFC3986)?
* If the spec does not make the syntax of targets more formal, I think it could generate collisions with the chosen markup and delimiter, whatever they are.
* When you look at WikiMatrix internal/external links comparisons, the meaning of the description part of the link changes somewhat between internal and external links and the position (order) of the description in the link. If Creole accepts any order, it could generate ambiguous situations but make the order less relevant. So let's try again :
# I have one existing wiki page called Foo. {{{[[Foo|Bar]]}}} would generate [Bar|Foo].
# I have one existing wiki page called Bar. {{{[[Foo|Bar]]}}} would generate [Foo|Bar].
# I have two existing wiki pages: Foo and Bar. {{{[[Foo|Bar]]}}} would generate [Foo|Bar] (hyperlinked text is the first part of the link by default).
The questions are:
* How could Creole make the third example less ambiguous if the order is not relevant?
* In the first example, a problem arises when someone creates a page called "Bar" afterward... The rendering will change for the one in example 3. Is that OK?
* What if the markup/delimiter is part of the Text or Target? (That's a recurrent question for any markup)
So, IMHO, we have a couple of things to settle:
# Creole "support" of implicit links
# The order of the text and the target (should we care?)
# The markup itself "[[[" "]]" and the field delimiter pipe "|". (I think we have a consensus on that point).
# How formal the syntax of the target should be
-- [EricChartre], 2007-01-02
Thank you for your clarification, I think I understand it better now. Personally I'm still somewhat charmed by the (mentioned before here) approach you suggested recently -- defininng only the absolute minimum we really need for interoperability and disambiguing things, and leave as much detail as possible to the implementers.
On the other hand, I agree that the details you mentioned can be problematic and thus should be defined. We can take the following approach:
__For URLs in text__ (without any markup), use somewhat generous matching algorithm, for example a regexp like {{{\w+//:\S[^,.:;?!|'")\]\}\s]}}}. Obviously, this is not **correct** implementation -- it won't match legitimate urls ending with a comma or dot and such, and it will match more url-like things that are really defined. But it follows the usus. People often put commas or periods or other punctuation right after the ulrs in the text. At the same time, sane URLs rarely even use these characters (except the dot), not to mention ending with them -- you can always use the {{{[[...]]}}} markup to force them.
__For the URLs in links__ (with the {{{[[...]]}}} markup), I'd say that anything that matches '^\w+://' is an URL (external link), while anything else is a page name (some wikis can also check the validity of the page names and refuse to parse malformed links, of course).
__The text and target order__ problem is in my opinion impossible to solve without introducing a totally new markup for links (so that it doesn't collide with existing ones). As you noticed, your approach can change the links of an existing document -- it may be an old and established wiki page, and the change can make it say something totally different than before, and the change won't even appear in the recent changes. That pretty much breaks peer review -- one of the most fundamental mechanisms in wikis.
The used order has an additional advantage -- since the "{{{|}}}" character is forbidden both in URLs, and in most wiki page names, you don't need any kind of escaping, and you can freely use additional pipe characters in the link text. It would be impossible the other way around.
What do you think, is it enough?
-- RadomirDopieralski, 2006-01-02
-- [[JasonBurnett]], 2008-Oct-05
Version Date Modified Size Author Changes ... Change note
46 05-Oct-2008 17:38 4.08 kB 69.243.201.36 to previous
45 25-Mar-2008 08:16 3.983 kB ChristophSauer to previous | to last respond to Carl
44 25-Mar-2008 05:04 3.85 kB CarlCravens to previous | to last
43 16-Oct-2007 10:01 3.022 kB ChristophSauer to previous | to last moved from talk
42 26-Sep-2007 09:06 2.114 kB ChuckSmith to previous | to last restore
41 26-Sep-2007 00:57 2.124 kB 219.138.204.162 to previous | to last
« This page (revision-46) was last changed on 05-Okt-2008 17:38 by 69.243.201.36