Re: [xwiki-devs] Questions, Gsoc2016, XWiki Android-authenticator

[Fitz Lee]

Hi Thomas,


Thank you so much for your reply and recognition.


2016-04-12 17:18 GMT+08:00 Thomas Mortagne :

> Hi Fitz,
>
> Great to see so much motivation from you :)
>
> Just don't forget that GSOC coding period is not started yet and that
> we still have no idea how many slots Google will give us and who we
> will select this year (this will be 22nd April).
>
>
Yeah, I know the coding period of GSoC, and now I'm just striving and
looking forward to get this project. If I really do not pass the GSoC
application, it doesn't matter and I have learned a lot. As I have said, I
will be very happy if there is anything I can help.


> Yes contact synchronization in
> https://github.com/xwiki-contrib/android-authenticator is not the
> beginning or an experiment I never had time to finish so it's more
> pseudo code that never worked yet.


Considering the XWikiRESTfulAPIs in
http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI, the apis
have been well designed so that maybe I can't modify those apis. I should
just make use of the existing api resources to design the synchronization
of contacts and the process of sign-in and sign-up.

Since there isn't the api like "/sync" in sampleSyncAdapter
google-engine-server, which can help us to get update contacts when sending
the phone's dirty contacts and the last time of synchronization to server,
we cann't use the synchronization mechanism in SampleSyncAdapter. I think
maybe we can use the following method to synchronize contacts.

* server to client (update local contacts from server when needed):
In the function, SynAdapter.onPerformSync(), the process is
"XWikiConnector.getAllUsers>> compare with the local contacts and find the
contacts which should be updated >> ContactManager.updateContacts".
Available apis:
GetAllUserList: curl
http://localhost:8080/xwiki/rest/wikis/query?q=object:XWiki.XWikiUsers
GetUserInfo: curl
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0

* client to server (edit, add, delete contacts and meanwhile synchronize
from client to server):
When editing, adding or deleting contacts in android activities, we should
first request the xwiki server. Update contacts if allowed, or discard the
modification if not be authorized or have no permission.
Available apis:
EditUser: curl -u FitzLee:fitz2xwiki -X PUT -H "Content-type:
application/x-www-form-urlencoded" -H "Accept: application/xml" -d
"className=XWiki.XWikiUsers" -d "property#company=iie"
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/FitzLee/objects/XWiki.XWikiUsers/0

I see two main possibility for this:
> * the first thing you should do I think is download the jetty/hsqld
> all in one distribution on
> http://www.xwiki.org/xwiki/bin/view/Main/Download and use that as test
> server (you have admin right in it and can create as many test users
> or groups as you want)
> * as soon as you want to test volume and compatibility with existing
> instance of XWiki you can register on http://www.xwiki.org which
> contains 1519 users right now
>

I have downloaded the enterprise xwiki jetty server 8.0 and tried to create
some applications and understand the features of the server. Using the
administrator Admin:admin, I have create some users and groups. And I use
the python script curl to learn how to get user-list, group-list and how to
modify them with the restfull apis. In addition, I find a demo which is
useful for me to be familiar with the apis, like
xwiki-contrib/android-client(https://github.com/xwiki-contrib/android-client).
And I will write my own android restful interactive method, mainly used for
the authentication and the management of users and groups.

But for testing the volume and compatibility of the synchronization in
SynAdapter.onPerformSync(), how do we compare the contact differences
between server and client and find the update contacts which need to be
updated?  It's a big problem if there are 1519 users and maybe I should
compare one by one to find which contact should be updated because
there'are no relevant apis to get the need-to-update contacts from server
after the last time of synchronization.

> (1) sign in
> > it is easy,just like my analysis of android SampleSyncAdapter, including
> the
> > server connection with XWikiconnector and the account added by
> > AccountManager
>
> Don't reduce too quickly the level of difficulty on this side, one
> thing you will have to work around is that standard XWiki instance
> have no token based authentication so you will have to hack an as safe
> as possible BASIC auth based implementation of Android authenticator
> (which mean users of the authenticator can't just ask for the token
> and connect to XWiki server).


Thank you for your reminder.  From the restfull apis, I have seen the two
methods of authentication,  including HTTP BASIC Auth and XWiki session
auth.  But Question is how users of the authenticator to connect 

Re: [xwiki-devs] [xwiki-users] DocumentDeletingEvent

[Sergiu Dumitriu]

On 04/13/2016 03:10 AM, Thomas Mortagne wrote:
> On Tue, Apr 12, 2016 at 10:11 PM, Vincent Massol  wrote:
>> Hi Peter,
>>
>>> On 05 Apr 2016, at 19:28, Peter Huisman  wrote:
>>>
>>> From the XWiki source code, I see there is a difference in passing a 
>>> document to the evenmanager:
>>>
>>> The DocumentDeletingEvent is passing a “new 
>>> XWikiDocument(doc.getDocumentReference())"
>>> The DocumentUpdatedEvent (as an example) is passing the doc (the actual 
>>> XWikiDocument)
>>>
>>> The difference is, that the Document passed in the DeleteEvent is a new 
>>> XWikiDocument and not the XWikiDocument that is about to be deleted.
>>>
>>> Is there a reason why this difference exists?
>>
>> he code in the XWiki class doing the notify has been there for a long time 
>> AFAICS:
>>
>> om.notify(new DocumentDeletingEvent(doc.getDocumentReference()),
>> new XWikiDocument(doc.getDocumentReference()), context);
>>
>> However, I think it’s not correct. I think it should pass the document and 
>> not a clone, because an Event Listener should be able to modify the instance 
>> that’s going to be saved.
> 
> It's a delete not a save so modifying it would be useless. I guess the
> intend here was to have the same kind of data than what you get with
> DocumentDeletedEvent.
> 
> What is wrong and should be fixed is that the document sent with the
> event should have the real one as original document (exactly like it's
> done for DocumentDeletedEvent).

Thomas is right, the data sent in the event is supposed to be what the
database will contain after the event is done, and that's what will
(apparently, but not actually) be in the database after the delete: a
new blank document, and doc.originalDoc should be what was before the
change in the database. At least this was the original intention, all
events should behave like this, so that a diff can be computed between
doc and originalDoc regardless of what action happened to the document.

However, the Javadoc for DocumentDeletingEvent is misleading:
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-bridge/src/main/java/org/xwiki/bridge/event/DocumentDeletingEvent.java#L31

>>
>> So I’d open a bug for this. Let’s see if the others agree.
>>
>> Thanks
>> -Vincent
>>


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to get space name(s) when I execute macro in java?

[Vincent Massol]

> On 13 Apr 2016, at 12:10, Vincent Massol  wrote:
> 
> 
>> On 13 Apr 2016, at 12:05, Vincent Massol  wrote:
>> 
>> You have this information in the TransformationContext by walking the XDOM 
>> upward and finding a location metadata
> 
> It’s called “source” actually, see
> https://github.com/xwiki/xwiki-rendering/blob/7cac6e9dc68d6334deaf947cc15d8cde4dd7ee4b/xwiki-rendering-api/src/main/java/org/xwiki/rendering/listener/MetaData.java#L43-L43
> 
> Example code to do this:
> https://github.com/xwiki/xwiki-rendering/blob/9fbb0423b93290463f2d27ae6be2fea473ed93f2/xwiki-rendering-transformations/xwiki-rendering-transformation-linkchecker/src/main/java/org/xwiki/rendering/internal/transformation/linkchecker/LinkCheckerTransformation.java#L172-L172

I’ve documented it quickly at:
http://rendering.xwiki.org/xwiki/bin/view/Main/ExtendingMacro#HFindingthelocationoftheMacro

Hope it helps

Thanks
-Vincent

> 
> Thanks
> -Vincent
> 
>> 
>> Thanks
>> -Vincent
>> 
>>> On 13 Apr 2016, at 11:21, abtv  wrote:
>>> 
>>> I extended AbstractMacro with my class. When I execute macro with `execute`
>>> function I don't have access to the space name on which the macro is called.
>>> I would like to customize output depending on the current space. All I need
>>> is just space name as a string. How to get space name inside `execute`
>>> function? I suppose it can be some dependency injection, but I'm don't know
>>> what to use.
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://xwiki.475771.n2.nabble.com/How-to-get-space-name-s-when-I-execute-macro-in-java-tp7598966.html
>> 
> 

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Eduard Moraru]

On Wed, Apr 13, 2016 at 11:15 AM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> I don't like the option 2 because it mentions "space" which is not
> presented in the UI and which will disappear eventually.
>
> On the other hand, option 3 has the drawback of writing "WebHome"
> everywhere, which is again something we want to hide.
>
> Since we have recently decided that "page" should be the word used instead
> of "document", and since the creation of "terminal page" is only an option
> for advanced users, I propose to introduce the type "page" as an alias of
> "space".
>
> So to link a terminal page, we would use "doc:A.B" and to link a nested
> page, we would use "page:A.B" (which will be resolved as A.B.WebHome). No
> ambiguity.
>
> With that proposition, I would be for the option 2
>
> I'm sorry to hijack the vote with a new proposition, but I though it was
> important.
>

I was actually thinking of the same thing. Maybe we should have chosen
"page" from the start. If we move to "page" I would prefer to replace
"space" instead of adding yet another alias for it (which would not be as
trivial as it seems) since we`re still rather early in the Nested Page
adoption. We could probably try some migrator as well for that.

|

Regarding the link syntax complexity, IMO the source of all these issues is
the "default" and "indirect"/"accidental" relativity of [[A]] links. I say
"indirect"/"accidental" because it`s not designed, IMO, but only a side
effect of the way the reference resolver works and, together with the
"relative" effect, we also get all these weird limitations that don`t make
sense for a user wanting page references and not document references (witch
also have a space element).

A solution to this, IMO, would be to make references absolute by default
and have relative links be explicit (probably with the [[.A]] notation and
the [[..A]] notation for parent, as Vincent was saying). Migrations would
be problematic though.

Another solution (maybe more manageable in terms of migrations, and more
user friendly) would be a new link syntax, as Vincent again mentioned, but
then we would find ourselves translating the link syntax to the reference
syntax which would now diverge (even more than they did in order to be able
to avoid ".WebHome").

|

Regarding the actual issue at hand, I agree with Marius on the 3rd option,
since that is what I have also implemented in the WYSIWYG (in order to
accept the new "space:" link type) and it does make sense from a visual
editor point of view. If users use a visual editor they should not care
about what it produces. Think of the old DreamWeaver solution or any other
visual tool that produces code... it will never be pretty code but it will
work and you can never expect it to be pretty enough, as if a human wrote
it. It needs to cover many use cases as best as possible, whereas if a
human wrote it, it would cover a single specific use case very neatly. If
some users use WYSIWYG and others use wiki syntax there will surely be some
friction by design and I don`t see how we can get around it.

Thanks,
Eduard

WDYT?
>
> Thanks,
>
>
>
> 2016-04-12 16:29 GMT+02:00 Vincent Massol :
>
> >
> > > On 12 Apr 2016, at 16:18, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> > >
> > > On Tue, Apr 12, 2016 at 5:12 PM, Thomas Mortagne <
> > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > >> On Tue, Apr 12, 2016 at 4:09 PM, Vincent Massol 
> > >> wrote:
> > >>>
> >  On 12 Apr 2016, at 15:43, Marius Dumitru Florea <
> > >> mariusdumitru.flo...@xwiki.com> wrote:
> > 
> >  On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol  >
> > >> wrote:
> > 
> > > Hi Marius,
> > >
> > >> On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
> > > mariusdumitru.flo...@xwiki.com> wrote:
> > >>
> > >> Hi devs,
> > >>
> > >> We need to decide what is the expected link reference
> serialization
> > >> produced by the WYSIWYG editor when you create a link to a wiki
> > page.
> > >> I
> > >> think we have to choose between 3 options:
> > >>
> > >> (1) Output untyped (ambiguous) link references whenever possible
> > >> (2) Always output unambiguous (typed) link references (both 'doc:'
> > and
> > >> 'space:')
> > >> (3) Always output 'doc:' link references (no 'space:' references)
> > >>
> > >> Let's see the details:
> > >>
> > >> = OPTION 1: Output untyped link references whenever possible =
> > >>
> > >> == <7.2 ==
> > >>
> > >> Link from A.B
> > >> * to A.WebHome (space home page) => [[WebHome]]
> > >> * to A.C (same space) => [[C]]
> > >
> > > I don’t understand why you’re using relative links in your 2
> examples
> > > above. Option (1) says untyped, it doesn’t say convert links into
> > >> relative
> > > links.
> > >
> > > So for me that would be:
> > >
> > > * to 

Re: [xwiki-devs] How to get space name(s) when I execute macro in java?

[Vincent Massol]

> On 13 Apr 2016, at 12:12, Thomas Mortagne  wrote:
> 
> It depends you want the current space or the space where the document
> calling the macro is located. They could be different in case of
> include for example.

Indeed. I was answering to: " I don't have access to the space name on which 
the macro is called.”

Thanks
-Vincent

> On Wed, Apr 13, 2016 at 12:10 PM, Vincent Massol  wrote:
>> 
>>> On 13 Apr 2016, at 12:05, Vincent Massol  wrote:
>>> 
>>> You have this information in the TransformationContext by walking the XDOM 
>>> upward and finding a location metadata
>> 
>> It’s called “source” actually, see
>> https://github.com/xwiki/xwiki-rendering/blob/7cac6e9dc68d6334deaf947cc15d8cde4dd7ee4b/xwiki-rendering-api/src/main/java/org/xwiki/rendering/listener/MetaData.java#L43-L43
>> 
>> Example code to do this:
>> https://github.com/xwiki/xwiki-rendering/blob/9fbb0423b93290463f2d27ae6be2fea473ed93f2/xwiki-rendering-transformations/xwiki-rendering-transformation-linkchecker/src/main/java/org/xwiki/rendering/internal/transformation/linkchecker/LinkCheckerTransformation.java#L172-L172
>> 
>> Thanks
>> -Vincent
>> 
>>> 
>>> Thanks
>>> -Vincent
>>> 
 On 13 Apr 2016, at 11:21, abtv  wrote:
 
 I extended AbstractMacro with my class. When I execute macro with `execute`
 function I don't have access to the space name on which the macro is 
 called.
 I would like to customize output depending on the current space. All I need
 is just space name as a string. How to get space name inside `execute`
 function? I suppose it can be some dependency injection, but I'm don't know
 what to use.
 
 
 
 --
 View this message in context: 
 http://xwiki.475771.n2.nabble.com/How-to-get-space-name-s-when-I-execute-macro-in-java-tp7598966.html
>>> 
>> 
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
> 
> 
> 
> -- 
> Thomas Mortagne
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to get space name(s) when I execute macro in java?

[Thomas Mortagne]

It depends you want the current space or the space where the document
calling the macro is located. They could be different in case of
include for example.


On Wed, Apr 13, 2016 at 12:10 PM, Vincent Massol  wrote:
>
>> On 13 Apr 2016, at 12:05, Vincent Massol  wrote:
>>
>> You have this information in the TransformationContext by walking the XDOM 
>> upward and finding a location metadata
>
> It’s called “source” actually, see
> https://github.com/xwiki/xwiki-rendering/blob/7cac6e9dc68d6334deaf947cc15d8cde4dd7ee4b/xwiki-rendering-api/src/main/java/org/xwiki/rendering/listener/MetaData.java#L43-L43
>
> Example code to do this:
> https://github.com/xwiki/xwiki-rendering/blob/9fbb0423b93290463f2d27ae6be2fea473ed93f2/xwiki-rendering-transformations/xwiki-rendering-transformation-linkchecker/src/main/java/org/xwiki/rendering/internal/transformation/linkchecker/LinkCheckerTransformation.java#L172-L172
>
> Thanks
> -Vincent
>
>>
>> Thanks
>> -Vincent
>>
>>> On 13 Apr 2016, at 11:21, abtv  wrote:
>>>
>>> I extended AbstractMacro with my class. When I execute macro with `execute`
>>> function I don't have access to the space name on which the macro is called.
>>> I would like to customize output depending on the current space. All I need
>>> is just space name as a string. How to get space name inside `execute`
>>> function? I suppose it can be some dependency injection, but I'm don't know
>>> what to use.
>>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://xwiki.475771.n2.nabble.com/How-to-get-space-name-s-when-I-execute-macro-in-java-tp7598966.html
>>
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to get space name(s) when I execute macro in java?

[Vincent Massol]

> On 13 Apr 2016, at 12:05, Vincent Massol  wrote:
> 
> You have this information in the TransformationContext by walking the XDOM 
> upward and finding a location metadata

It’s called “source” actually, see
https://github.com/xwiki/xwiki-rendering/blob/7cac6e9dc68d6334deaf947cc15d8cde4dd7ee4b/xwiki-rendering-api/src/main/java/org/xwiki/rendering/listener/MetaData.java#L43-L43

Example code to do this:
https://github.com/xwiki/xwiki-rendering/blob/9fbb0423b93290463f2d27ae6be2fea473ed93f2/xwiki-rendering-transformations/xwiki-rendering-transformation-linkchecker/src/main/java/org/xwiki/rendering/internal/transformation/linkchecker/LinkCheckerTransformation.java#L172-L172

Thanks
-Vincent

> 
> Thanks
> -Vincent
> 
>> On 13 Apr 2016, at 11:21, abtv  wrote:
>> 
>> I extended AbstractMacro with my class. When I execute macro with `execute`
>> function I don't have access to the space name on which the macro is called.
>> I would like to customize output depending on the current space. All I need
>> is just space name as a string. How to get space name inside `execute`
>> function? I suppose it can be some dependency injection, but I'm don't know
>> what to use.
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://xwiki.475771.n2.nabble.com/How-to-get-space-name-s-when-I-execute-macro-in-java-tp7598966.html
> 

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to get space name(s) when I execute macro in java?

[Vincent Massol]

You have this information in the TransformationContext by walking the XDOM 
upward and finding a location metadata

Thanks
-Vincent

> On 13 Apr 2016, at 11:21, abtv  wrote:
> 
> I extended AbstractMacro with my class. When I execute macro with `execute`
> function I don't have access to the space name on which the macro is called.
> I would like to customize output depending on the current space. All I need
> is just space name as a string. How to get space name inside `execute`
> function? I suppose it can be some dependency injection, but I'm don't know
> what to use.
> 
> 
> 
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/How-to-get-space-name-s-when-I-execute-macro-in-java-tp7598966.html

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to get space name(s) when I execute macro in java?

[Guillaume Delhumeau]

Try to inject DocumentAccessBridge:
https://github.com/xwiki/xwiki-platform/blob/a28f5d4f98b5011e59fd0781ea608dec0a934386/xwiki-platform-core/xwiki-platform-bridge/src/main/java/org/xwiki/bridge/DocumentAccessBridge.java#L69

2016-04-13 11:21 GMT+02:00 abtv :

> I extended AbstractMacro with my class. When I execute macro with `execute`
> function I don't have access to the space name on which the macro is
> called.
> I would like to customize output depending on the current space. All I need
> is just space name as a string. How to get space name inside `execute`
> function? I suppose it can be some dependency injection, but I'm don't know
> what to use.
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/How-to-get-space-name-s-when-I-execute-macro-in-java-tp7598966.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] How to get space name(s) when I execute macro in java?

[abtv]

I extended AbstractMacro with my class. When I execute macro with `execute`
function I don't have access to the space name on which the macro is called.
I would like to customize output depending on the current space. All I need
is just space name as a string. How to get space name inside `execute`
function? I suppose it can be some dependency injection, but I'm don't know
what to use.



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/How-to-get-space-name-s-when-I-execute-macro-in-java-tp7598966.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Link reference serialization in WYSIWYG editor output

[Guillaume Delhumeau]

I don't like the option 2 because it mentions "space" which is not
presented in the UI and which will disappear eventually.

On the other hand, option 3 has the drawback of writing "WebHome"
everywhere, which is again something we want to hide.

Since we have recently decided that "page" should be the word used instead
of "document", and since the creation of "terminal page" is only an option
for advanced users, I propose to introduce the type "page" as an alias of
"space".

So to link a terminal page, we would use "doc:A.B" and to link a nested
page, we would use "page:A.B" (which will be resolved as A.B.WebHome). No
ambiguity.

With that proposition, I would be for the option 2

I'm sorry to hijack the vote with a new proposition, but I though it was
important.

WDYT?

Thanks,



2016-04-12 16:29 GMT+02:00 Vincent Massol :

>
> > On 12 Apr 2016, at 16:18, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Tue, Apr 12, 2016 at 5:12 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> >> On Tue, Apr 12, 2016 at 4:09 PM, Vincent Massol 
> >> wrote:
> >>>
>  On 12 Apr 2016, at 15:43, Marius Dumitru Florea <
> >> mariusdumitru.flo...@xwiki.com> wrote:
> 
>  On Tue, Apr 12, 2016 at 4:30 PM, Vincent Massol 
> >> wrote:
> 
> > Hi Marius,
> >
> >> On 12 Apr 2016, at 14:56, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >>
> >> Hi devs,
> >>
> >> We need to decide what is the expected link reference serialization
> >> produced by the WYSIWYG editor when you create a link to a wiki
> page.
> >> I
> >> think we have to choose between 3 options:
> >>
> >> (1) Output untyped (ambiguous) link references whenever possible
> >> (2) Always output unambiguous (typed) link references (both 'doc:'
> and
> >> 'space:')
> >> (3) Always output 'doc:' link references (no 'space:' references)
> >>
> >> Let's see the details:
> >>
> >> = OPTION 1: Output untyped link references whenever possible =
> >>
> >> == <7.2 ==
> >>
> >> Link from A.B
> >> * to A.WebHome (space home page) => [[WebHome]]
> >> * to A.C (same space) => [[C]]
> >
> > I don’t understand why you’re using relative links in your 2 examples
> > above. Option (1) says untyped, it doesn’t say convert links into
> >> relative
> > links.
> >
> > So for me that would be:
> >
> > * to A.WebHome (space home page) => [[A.WebHome]]
> > * to A.C (same space) => [[A.C]]
> >
> >> * to X.Y (different space) => [[X.Y]]
> >> * to X.WebHome => [[X.WebHome]]
> >>
> >> == 7.2+ ==
> >>
> >> Link from A.B.WebHome
> >> * to A.WebHome (its parent) => [[space:A]]
> >
> > Note 1: We could also imagine introducing a syntax for absolute links
> >> such
> > as [[:A]]
> > Note 2: We could also imagine introducing a syntax for parent links
> >> such
> > as [[..A]]
> >
> >> * to A.B.C or A.B.C.WebHome or A.C or A.C.WebHome (child or sibling)
> >> =>
> >> [[C]] (very ambiguous)
> >
> > This is using a relative notation. But (1) is not about transforming
> >> links
> > into relative links.
> >
> > so for me this is:
> > * => [[A.B.C]]
> > * => [[A.C]]
> >
> > I’m stopping reading here since first we need to clarify if (1) is
> >> about
> > a) untyped or b) using relative references.
> >
> > IMO it should be about a) and doesn’t have to do b).
> >
> >
> 
> > Maybe I misunderstood something?
> >
> 
>  Generating relative references is a must for me (whenever possible),
> no
>  matter what output format we choose. I'm surprised there's any doubt
> >> about
>  this. The current WYSIWYG editor is generating relative references and
> >> the
>  CKEditor should continue to do this. Relative references have many
>  advantages (eases the refactoring, allows you to export a hierarchy
> and
>  import it somewhere else, etc.).
> >>>
> >>> Didn’t realize the WYSIWYG was already doing this!
> >>>
> >>> Indeed there are pros. The cons is that it can make the linking more
> >> ambiguous., but overall it’s probably a good thing.
> >>>
> >>
> >>> Also note that ideally we’d need to not convert existing links when
> >> going through the WYSIWYG editor. That’s true independently of this
> >> discussion though.
> >>
> >>
> >
> >> This is handled by XML comments containing the source reference so the
> >> only thing the WYSIWYG need to do is to not touch those comments
> >> (unless the user explicitly modify the target of course).
> >>
> >
> > It's already the case. The link reference is preserved as is unless you
> > edit the link and apply the changes (i.e. you close the link dialog with
> > the OK button).
>
> Note that the majority of users will edit a link and click ok even if they
>