Re: [Apache Bloodhound] #390: Product wiki syntax

[Gary Martin <ga...@wandisco.com>]

On 21/02/13 10:14, Andrej Golcov wrote:
> Regarding prefixing tickets with "#".
> We still have to support #123 notation for wiki links inside the
> product. IMHO, introducing non-relative wiki links for tickets without
> # (e.g. bh/123)   can be user confusing. My +1 to leave # for full
> path tickt links, e.g. #produc<delimeter>productid
>
> Regards, Andrej

In case it isn't spotted from another related thread, I believe that 
when using # in the link, it should always appear after any product 
specification. The forms for the links will therefore be

  * <reslink>
  * product:<prefix>:<reslink>
  * <prefix><sep><reslink>

where <reslink> is any currently valid resource link (#<id>, 
ticket:<id>, milestone:<id>, wiki:<id> etc). In addition, specifically 
for tickets and wiki pages we will allow:

  * <prefix><sep><id>

as long as the wiki page matches the current rules for automatically 
being interpreted as wikipage links. On this basis we will be able to 
match the the form of jira tickets if we choose <sep> = '-' and maybe we 
should just do so. Some of the things to consider for that are:

  * false matches on 'var-N' which would either have to be escaped by
    one of the standard means or just written as 'var - N'
  * potential ambiguity if '-' is allowed in the prefix itself, which
    might suggest we should avoid the issue by disallowing products
    being set up with '-' in the prefix; existing products with this
    will work with 'product:<prefix>:<reslink>' syntax of course.

Does anyone spot any additional problems or have any objections to this?

Cheers
     Gary

Re: [Apache Bloodhound] #390: Product wiki syntax

[Olemis Lang <ol...@gmail.com>]

On 3/5/13, Gary Martin <ga...@wandisco.com> 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.

Re: [Apache Bloodhound] #390: Product wiki syntax

[Gary Martin <ga...@wandisco.com>]

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...

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.

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.

Cheers,
    Gary

Re: [Apache Bloodhound] #390: Product wiki syntax

[Olemis Lang <ol...@gmail.com>]

I have been tempted to write a long reply , but I won't . I'll just
reply quicly between the lines . Product wiki syntax is almost ready
and working . I'm just writing test cases to cover all forms and deal
with some exotic . I propose we focus our efforts on discussing about
how to improve what I'll submit in the next few days , once we all be
aware of the limitations and technical challenges solved and pending
;)

BTW , After getting my hands dirty I realized that *many* of the
previous suggestions mentioned before are not even valid TracLinks
expressions . That will shape the form of the final solution though .

On 3/4/13, Gary Martin <ga...@wandisco.com> wrote:
> On 21/02/13 10:14, Andrej Golcov wrote:
>> Regarding prefixing tickets with "#".
>> We still have to support #123 notation for wiki links inside the
>> product. IMHO, introducing non-relative wiki links for tickets without
>> # (e.g. bh/123)   can be user confusing. My +1 to leave # for full
>> path tickt links, e.g. #produc<delimeter>productid
>>
>> Regards, Andrej
>
> In case it isn't spotted from another related thread, I believe that
> when using # in the link, it should always appear after any product
> specification.

+1

> The forms for the links will therefore be
>
>   * <reslink>
>   * product:<prefix>:<reslink>
>   * <prefix><sep><reslink>
>

+1

> where <reslink> is any currently valid resource link (#<id>,
> ticket:<id>, milestone:<id>, wiki:<id> etc).

+1 ... though ... ;)

> In addition, specifically
> for tickets and wiki pages we will allow:
>
>   * <prefix><sep><id>
>

for tickets +1 . for wiki pages I'm not sure

> as long as the wiki page matches the current rules for automatically
> being interpreted as wikipage links. On this basis we will be able to
> match the the form of jira tickets if we choose <sep> = '-'

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)

> and maybe we
> should just do so. Some of the things to consider for that are:
>
>   * false matches on 'var-N' which would either have to be escaped by
>     one of the standard means or just written as 'var - N'

+1

>   * potential ambiguity if '-' is allowed in the prefix itself,

in any case only alphanumeric (inlcuding unicode) chars will be
supported in short forms .

>     which
>     might suggest we should avoid the issue by disallowing products
>     being set up with '-' in the prefix; existing products with this
>     will work with 'product:<prefix>:<reslink>' syntax of course.
>

Other kinds of prefixes will make use of link resolvers only .

> Does anyone spot any additional problems or have any objections to this?
>

let the test suite talk , please be patient
;)

-- 
Regards,

Olemis.