You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the eccentricities of the JBoss Fuse library is that we use olink elements a lot, not only for linking within a book, but also for linking between different books in the same library. Now, these are different cases, so I will go through them separately.
First, using olink to define a link to an element in the same book. Here is an example of this olink syntax:
<olink targetptr="TargetID"/>
Which can easily be rendered in AsciiDoc as:
<<TargetID>>
Second, using olink to define a link to an element in a different book in the same library. Well, we don't really have a proper solution for this case at the moment (thought it will probably be solved soon in the context of Docs 2.0). My strategy to deal with this kind of olink is to preserve the metadata through the conversion to AsciiDoc and then deal with it later. Here is an example of this olinksyntax:
This is legal AsciiDoc syntax, but will not be processed, since olink: is an unknown scheme. This would give me a handy placeholder which I can search and replace some time in the future, when we have worked out a more permanent solution.
The text was updated successfully, but these errors were encountered:
One of the eccentricities of the JBoss Fuse library is that we use
olink
elements a lot, not only for linking within a book, but also for linking between different books in the same library. Now, these are different cases, so I will go through them separately.First, using
olink
to define a link to an element in the same book. Here is an example of thisolink
syntax:Which can easily be rendered in AsciiDoc as:
Second, using
olink
to define a link to an element in a different book in the same library. Well, we don't really have a proper solution for this case at the moment (thought it will probably be solved soon in the context of Docs 2.0). My strategy to deal with this kind ofolink
is to preserve the metadata through the conversion to AsciiDoc and then deal with it later. Here is an example of thisolink
syntax:I suggest converting it to AsciiDoc as follows:
This is legal AsciiDoc syntax, but will not be processed, since
olink:
is an unknown scheme. This would give me a handy placeholder which I can search and replace some time in the future, when we have worked out a more permanent solution.The text was updated successfully, but these errors were encountered: