On 3/5/13, Gary Martin <[email protected]> wrote: > On 04/03/13 22:39, Olemis Lang wrote: >> even if we don't choose sep = '-' it seems it may be matched >> >> so far I have discarded these chars as prefixes >> >> / collisions with relative wiki page refs in wiki context >> - has a major ambiguity when it comes to expanding raw-attachment and >> similar TracLinks namespace >> : TracLinks meta-char , obviously out >> . collisions with relative wiki >> >> I'm starting to think that we should be using one of ~ > >> >> 1. prefix~#123 >> 2. prefix>#123 >> >> ... or a combination of the former e.g. >> >> 3. prefix->#123 >> >> I think I'd rather prefer 1 or 3 . In the first version I'll implement >> (1) > > Well, I have considered those and I might compromise (I prefer '>') but... >
ok . I'll use that . No problem . ;) > The case of raw-attachment is a very good point. However, it is possible > to get around it and it also has a particular major advantage if we ever > get people to defect from jira. In order to achieve that I would be > prepared to drop the requirement to be able to use the short form for > anything other but tickets. In particular PREFIX-123 would be the > important case. > +1 > If we are interested in more, it would be possible to get away with '-' > under more conditions by specifying only uppercase namespaces are > allowed or making by deciding how a clash with other link resolvers will > be resolved. It should be noted that '-' is a problem for > 'raw-attachment' because of 'attachment'. > > It might be annoying for the raw product that you are unable to refer to > attachments in that form but from within the product I still expect > users to be able to drop the prefix and externally there is still the > product:raw:attachment: form. > The fact is that external link resolvers (i.e. wiki syntax extensions) will be matched first , so afaict the result of making both work side-by-side will be the impossibility of using raw-attachment prefix at all , i.e. no fallback possible -- Regards, Olemis.
