SupportRelativeBracketedLinks

I'd like to have a way to use relative path names in bracketed links.

Let's say I have a tree of webs and sub-webs, eg:

WebA
  SubWebAA
    TopicAA1
    TopicAA2
  SubWebAB
    TopicAB1
    TopicAB2
...

Currently, it's a bit awkward to make links outside of the current sub-web. For example, if I want to make a link from TopicAB1 to TopicAA1, the syntax would be "WebA.SubWebAA.TopicAA1".

Something akin to the Unix ".." syntax might be useful here. I'm not tied to any particular syntax, but here's a possibility:

^.SubWebAA.TopicAAA

-- RichMorin

See also ImplementingLinkProposals

Both Foswiki::Func::normalizeWebTopicName() and Foswiki::Address normalize web names to use a / path separator; but permitting . separators does introduce ambiguities.

I'm reluctant to "geek up" the syntax until we're sure we really can't use ../

Example	Foswiki::Address->type() notes
../	parent web
../Foo.Bar	sibling web Foo, topic Bar
../Foo/	sibling web
../Foo	ambiguous: sibling web or parent web's topic
../Foo/Bar/	sibling web
../Foo/Bar	ambiguous: sibling web Foo/Bar or sibling web Foo, topic Bar (or parent web's topic Foo attachment Bar ?)
../Foo/Bar.Baz	sibling web Foo/Bar, topic Baz (or parent web's topic Foo, attachment Bar.Baz?)

Writing out the table above, I remember now why relative paths were going to complicate Foswiki::Address parsing - it supports web, topic, and attachment targets which can only be resolved confidently if addresses are written in 'normalized form' - although it DOES have a pretty nifty (IMHO exist-hinting, guess-and-check heuristic mode which usually does the right thing when given an 'ambiguous' string to parse.

The following are examples of 'normal form' (non-ambiguous) addresses which don't require any guess-and-check exist-hinting heuristics to resolve:

• Web/
• Web/SubWeb/
• Web/SubWeb.Topic
• Web/SubWeb.Topic@2
• Web/SubWeb.Topic/Attachment.pdf
• Web/SubWeb.Topic/Attachment.pdf@3

However, our ability to distinguish where a web name starts and ends by way of using a . to separate the web and topic name parts, falls apart if a relative address must being with ../.

I guess the normal form relative addresses could use ... to refer to a parent web's topic vs ../ to refer to a sibling web.

Example	Foswiki::Address->type() notes
../	parent web
...	invalid
../Foo.Bar	sibling web Foo, topic Bar
../Foo/	sibling web
...Foo	parent web's topic Foo
../Foo/Bar/	sibling web
../Foo/Bar	sibling web Foo, topic Bar
...Foo/Bar	parent web's topic Foo, attachment Bar
../Foo/Bar.Baz	sibling web Foo/Bar, topic Baz
...Foo/Bar.Baz	parent web's topic Foo, attachment Bar.Baz

Hrm, maybe we do need to geek up the syntax for addressing attachments after all...

-- PaulHarvey - 04 Jan 2012

> but permitting . separators [for webs] does introduce ambiguities.

Paul, does this only refer to Web.SubWeb.WebHome vs Web.SubWeb where the latter is a valid topic as well? Or are there any other ambiguities?

It only introduces ambiguities for any attempt to create a relative-path syntax making use of ../ - PH

Just for the records: I always disliked / as a separator for webs whereas . is used to separate the topic part in a web.topic string.

Using . to separate webs.subwebs from each other does work in 99.99% of all cases anyway. Only exception I recently came across is RedirectPlugin ... which sort of sux.

From a user's perspective using a dot as a separator for both webs and topics is a lot easier to grasp.

Surely '/' is less geeky and more familiar (URLs, filesystem paths) than '.', but I get your point - would be preferable to not bother with semantically significant path separators - so doing that requires "geeking up" address syntax with some special prefix notation (or suffix as per RestPlugin, which uses Web/Topic/topic.json ) - PH

These addresses look a lot less geeky for my taste.

Now, adding some kind of syntax prefix that can't be misunderstood as a proper web name should not add any ambiguities what so ever parsing web.topic strings .

The problem I see is: most plugins aren't ready to make use relative web names. Even when they do make proper use of the Func api like

my ($resolvedWebName, $resolvedTopicName) = Foswiki::Func::normalizeWebTopic($relativeWebName, $someWebAndOrTopicName);

..there is no way compute $resolvedWebName without taking other information into account, i.e. $session->{webName}. And this could be wrong or unexpected from the point of the calling code.

Remember plugin handlers are called with a $web parameter which holds the value of %WEB%, that is: the location where the TML macro was found. This is not the current web of the page currently being rendered as stored in $session->{webName} also known as %BASEWEB%.

So again: how should Foswiki::Func::normalizeWebTopic() compute $resolvedWebName (given there are no hints what so ever in the $someWebAndOrTopicName parameter)? Does it resolve $relativeWebName relative to %WEB% or %BASEWEB% in terms of TML? Do we need both?

-- MichaelDaum - 04 Jan 2012

Answered your other questions inline, but regarding the API issue, store2 refactoring is replacing ($web, $topic, $rev) tuples in core with Foswiki::Address objects (or compatible hash/refs which eventually get promoted to Foswiki::Address objects).

Presently, Foswiki::Address does not make any use of $session->{webName}, that's up the caller of Foswiki::Address->new(), Eg.

my $addrObj = Foswiki::Address->new(string => "../Sibling/Subweb.Topic", web => $session->{webName});

That would imply a default context to assume whenever an absolute web path cannot be determined from the parsed string value, which is already the case for strings such as Topic or Topic@3

-- PaulHarvey - 04 Jan 2012

Based on gut feel, I can see this causing grief.

WebA
  SubWebAA
    SubWebXX
      TopicAA1
      TopicAA2
    SubWebYY
      BananaBread
  SubWebAB
    SubWebXX
      TopicAB1
      TopicAB2
    SubWebYY
      BananaBread
...

What does SubWebXX/../SubWebYY/BananaBread refer to?

I'm not sure that this is even the point, maybe it can be resolved. I need to think about this more.

However, before I do, I would like to understand better why this feature would, for Foswiki kind in general, even be valuable.

RichMorin's original motivation was only about making it easier to write a link. Rich, could you not create a preference in a WebPreferences topic like * Set SUBWEBYY = SubWebYY and then use %SUBWEBYY%.!BananaBread? Assuming all your sub-webs have unique names, this would be very easy. If they have different names you can still do it; you just have to define a convention for your preference names.

Rich, is writing simpler links the only problem you are trying to solve? If there is some other problem this solves for then please let us know. If so, it would help us and you if you could describe the problem you are having so we can offer existing solutions. Please keep proposing solutions mind you, just remember that without knowing the background/problem, your solution could send us down the wrong path.

I'm also curious as to whether you plan to store relative links within topics. In other words, would a plugin that resolves relative links to absolute links during save also be a solution?

Paul, Michael: Am I missing some great potential in this idea? At the moment I see something that could take up a lot of work, because of corner cases and subsequently long term maintenance issues, for little benefit.

-- JulianLevens - 04 Jan 2012

I've had (a few) users ask if there was any such thing as a relative link syntax in Foswiki; but to be honest, I'd rather invest the time in fixing Foswiki editor(s) to better aid the user in building absolute links, than introduce relative link syntax

I am hopeful that a transition to Foswiki::Address in core & plugins will make an eventual relative link implementation easier

My concern presently is that

1. ../ kills the web/topic/attachment type disambiguation - there's no "normal" form that the user could type which would allow Foswiki::Address to confidently resolve such a string without using the exist-hinting heuristics
2. ../ is the only reasonably sane syntax we should implement

This is a mighty conflict! Options:

1. "Geek up" Foswiki::Address with some extra syntax to help the parser out, Eg. [[attachment:Web.Topic/Attachment.pdf]] which would lead to being able to make sense of where [[attachment:../Topic/Attachment.pdf]] should point to. I would be very disappointed if we suddenly want to go this way, because I tried hard to get feedback on this decision, but ultimately I'm happy to do whatever we can reach consensus for
2. Make a rule that relative links must always point to a topic, Eg. [[../SiblingWeb/Topic]]

Further questions:

1. Do we also support a '/' path prefix, Eg. [[/RootWeb/SubWeb.Topic]] syntax?
2. What to do with relative paths that try to walk higher than the root - truncate & try to make the path work? Or always refuse to resolve it?

-- PaulHarvey - 05 Jan 2012

I am really not sure relative links are worth it. A lot of good concerns have been raised above, last but not least the question: which web is a relative link actually relative to when content is %INCLUDEd from a different web?

-- MichaelDaum - 05 Jan 2012

What happens if a topic is reparented? That will break those relative links - they will link to another topic but you won't be able to see that. Is that desired behaviour?

-- ArthurClemens - 05 Jan 2012

Arthur, no, my understanding is that relative links are web-relative, but your question raises a good point - some users will try to connect the feature with TOPICPARENT

Michael: INCLUDE is able to understand which web a topic-only link should point to, Eg. [[TopicName]], so I can only assume it should be possible to traverse the web hierarchy if it's [[../../TopicName]] instead.

I'm not planning to do this work myself, but I could help out Rich if he wants to do the work.

I am mostly interested in the discussion to see if I need to change any of the other proposals I am planning to work on, to accommodate this as a future direction

-- PaulHarvey - 05 Jan 2012

The discussion above makes it clear that this is a trickier issue than I had thought. I'm also not sure that solving it is the most important thing folks should be working on, given the existence of workarounds such as variables.

However, as more complicated sub-web trees get used, this will become a more desirable feature. So, I'm glad we had the discussion and encourage folks to keep the question in mind...

-- RichMorin - 20 Feb 2012

Commenting is disabled while not logged in