Hi Dashamir! > in Fedora5. So, either you don't have the latest > version of DocBookWiki or you don't have Fedora5.
Neither nor. I have Debian and I don't have the latest version. I would be very suprised though if this was related to the Linux distro, but I think it will make sense to upgrade my installation, test again and report. Maybe it's related to the browser. What browser are you using? I am usually using Mozilla on Windows, but I can also give it a try using IE. Anyway, I will let you know. On the subject of markup: > Then, going a step further, to make things simple > (for the user, the documentation writter, not for > us the programmers), we can define implied cdata > sections to be like this: > This block: > --blocktag-- > abc > xyz > ---- > is equivalent to this: > --blocktag > <!CDATA[abc > xyz]]> > ---- I like the idea to have some inline markup for CDATA better. The difference between --blocktag ---- and --blocktag-- ---- is very subtle, isn't it? --[[ and ]]-- seem reasonable as inline markup to me. In general, I think properly designing the Wiki markup in a way that makes sense, is consistent and is easy to apply *for an editor* is an artform in itself IMO. I think the problem is this: Docbook gives you a ton of possible tags that can be applied. But the goal is that the Wiki markup is simpler to use by applying some "I know what you intend" kind of stuff. Basically, IMO the Wiki notation is about common sense. Nobody understands that you *have* to write <para>This is a paragraph</para> and your whole document becomes invalid if you forget to properly close a tag. So the markup using empty lines between paragraphs, the lists with *, _emphasis_ and the like really make it easier, and only if this is because if you get it wrong, i.e. you would use _highligh instead of _highlight_ your document would still save and display, you'd recognize it doesn't look the way you intended it to be and you can double-check. On the other hand I am not sure if it would make sense sometimes to just use specific docbook tags that I know I want to use rather than having to think what Wiki syntax might produce them. So maybe even an escape from Wiki test to plain docbook might make sense. I wonder if applying some formal grammar might clear this up a bit? Regards, Torsten Dashamir Hoxha schrieb: > Hi Torsten, > > First of all the problem of quotation marks inside > cdata does not happen to me. I tested the latest > version of DocBookWiki (from subversion) > in Fedora5. So, either you don't have the latest > version of DocBookWiki or you don't have Fedora5. > > I remember that sometimes in the past I had problems > with quotation marks, so I introduced some code > to fix it (by escaping them). However it turned out > that the problem actually was either with the > version of the browser or with the version or the > configuration of apache, so the fix was actually > *creating* problems (by introducing extra slashes). > So I removed it. > > About CDATA, I think that introducing > --cdata > ---- > would be OK. The parser does support nested blocks, > however, CDATA blocks, being somewhat different from > the XML elements, are handled in a special way; > they have to be preprocessed before the text/wiki > is submitted to the parser (this is what is done > currently with the <![CDATA[...]]> blocks). > > So, the parser will never have the chance to parse > the block --cdata, because it has been already > removed by the preprocessing stage. (There is > also a post-processing stage which puts them back > after the text/wiki is converted to XML/DocBook.) > > Since the matters are like this, then we don't > have to use a block-similar markup for denoting > CDATA sections. Any markup that does not create > ambiguity would be OK. So, I would propose to > use something like this: --[[xyz]]-- > hoping that '--[[' is not so common in the text > of documents and ']]--' may not be so common > in the content of cdata sections. Do you have > any better suggestion about these markups? > > They don't have to be symetric, they just have > to be simple and unambiguous (otherwise, if they > are not simple, then we better use <![CDATA[...]]> > itself). I think that it is also better to be > inline markup (instead of block markup), since > <![CDATA[...]]> itself is inline. > > Then, going a step further, to make things simple > (for the user, the documentation writter, not for > us the programmers), we can define implied cdata > sections to be like this: > This block: > --blocktag-- > abc > xyz > ---- > is equivalent to this: > --blocktag > <!CDATA[abc > xyz]]> > ---- > > I think that it can be usefull, in general. > > Regards, > Dashamir > > > --- Torsten Schlabach <[EMAIL PROTECTED]> wrote: > > >>Hi Dashamir, >> >> >>>About the suggestion, maybe it is better to keep >>>--code unmodified and to introduce another tag, >>>e.g. --code-- which would wrap the content in >>>CDATA. What do you think? >> >>I just had a look at "DocBook: The Definitive Guide" >>and you're probably right. There should not be an >>automatism to have a programlisting wrapped into a >>CDATA tag in any case because the docbook standard >>does allow for markup inside a program listing, >>which can be useful. >> >>But then, why not keep it simple and introduce >> >>--cdata >>---- >> >>so it would be >> >>--code >>--cdata >>your program listing here >>---- >>---- >> >>That would also allow for something like: >> >>--code >>--cdata >>some not so important code in the beginning >>---- >><emphasis> >>--cdata >>more code >>---- >></emphasis> >>---- >> >>Or would nested blocks cause a problem for the >>current version of the parser? >> >>WDYT? >> >>Regards, >>Torsten > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Doc-book-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/doc-book-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Doc-book-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/doc-book-users
