Hi, Guys...
I finish the first clean-up of the documentation. It consisted by: 1) remove all FAQ and DEVEL files considered empty in content (no content at all or just the default lines); 2) remove of the <RevHistory>/</RevHistory> tag (and of course anything Between them); 3) remove the comments at the EOF that beginned with "<!-- Keep this element at the end of the file";
The attached file (in ZIP format) is the resulting SVN DIFF file. It was applied over trunk version, revision 3761.
I would like to ask the developers how much is a good time to wait for comments and revisions before commiting the changes? 1 week? 10 days? Sugestions?
Edson
Hello,
On 02/26/08 22:27, Edson wrote:
Hi, Guys...
I finish the first clean-up of the documentation. It consisted by:
- remove all FAQ and DEVEL files considered empty in content (no content at all or just the default lines);
- remove of the <RevHistory>/</RevHistory> tag (and of course anything Between them);
- remove the comments at the EOF that beginned with "<!-- Keep this element at the end of the file";
Thanks, I believe we should think also the context of migrating to xml format. Anybody with some docbook xml experience? Hints, tips? I am investigating now the best way to migrate from sgml to xml.
If we are going to remove some file, add new ones, we need to have in mind the near future as well.
The attached file (in ZIP format) is the resulting SVN DIFF file. It was applied over trunk version, revision 3761.
I would like to ask the developers how much is a good time to wait for comments and revisions before commiting the changes? 1 week? 10 days? Sugestions?
Let's plan kind of to-do list/roadmap, to sync the work and check the milestones. Otherwise many will work on same task, or go totally different direction.
Cheers, Daniel
Edson
Openser-docs mailing list Openser-docs@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
Hi, Daniel... Guys...
So let's try to draw a first to-do list, so that the work can begin...
1- Migrate the existing DOCs from SGML to XML format: I'm not a DocBook expert but Henning and I already changed some thoughts on this. What's not clear to me is if this is just a translation matter or also a diagramatic problem? Translation is some kind of direct work, while diagramatic requires a previous discussion.
2- Suppress and/or Agregate new DOCs: Clean-up empty files (with a sort of "no content") is require, since there information can be gatered elsewhere, but agregate new DOCs is a sort of "asking for problems" approach, so I would say that some skeleton/template has to be defined. This has to become before this agregation issue. But this arises a problem: wich is the best 'skeleton'? Which kind of documentation will be present? How to automate it?
So this two points brings: 1- Documentation structure Skeleton/Template; 2- Documents Skeleton/Template defining chapter and, maybe, minimum section contents, definition of origin (directly from code? From Doxygen?) and, most important, responsibilities; 3- XML Style that translate/implement this skeleton/templates; 4- Conversion of actual SGML format to some DocBook-XML format;
Each of this points should define a milestone by itself and its end it could be marked with IRC meeting where the results could be presented and discussed.
Please these are only thoughs... so fell free to add more points and/or point me wrongs approaches.
Edson
-----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: terça-feira, 26 de fevereiro de 2008 18:37 To: Edson Cc: openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
Hello,
On 02/26/08 22:27, Edson wrote:
Hi, Guys...
I finish the first clean-up of the documentation. It consisted by:
- remove all FAQ and DEVEL files considered empty in content (no content at all or just the default lines);
- remove of the <RevHistory>/</RevHistory> tag (and of course anything Between them);
- remove the comments at the EOF that beginned with "<!-- Keep this element at the end of the file";
Thanks, I believe we should think also the context of migrating to xml format. Anybody with some docbook xml experience? Hints, tips? I am investigating now the best way to migrate from sgml to xml.
If we are going to remove some file, add new ones, we need to have in mind the near future as well.
The attached file (in ZIP format) is the resulting SVN DIFF file. It was applied over trunk version, revision 3761.
I would like to ask the developers how much is a good time to wait for comments and revisions before commiting the changes? 1 week? 10 days? Sugestions?
Let's plan kind of to-do list/roadmap, to sync the work and check the milestones. Otherwise many will work on same task, or go totally different direction.
Cheers, Daniel
Edson
Openser-docs mailing list Openser-docs@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
Hello Edson,
your points are very good. It is the skeleton/template we have to define primary. Here I see couple of items you should take in consideration: - ability to generate standalone readme per module and aggregate all in single document. Perhaps here we can have two documets in each module, one that will have the head/tag of a book, and the other, head/tag of a chapter -- they will be very small, just including the other documents. - module names, parameters name, function names, PV names, ..., must be clearly marked so we can extract very easy the index. You did the previous indexes in dokuwiki, and you know better how hard is to do it with the current structure. - the generated html formats should have all the time same anchor for parameters, functions, a.s.o, so that the reference will stay the same, even new elements are introduced. If I am not wrong, that is possible by setting an unique 'id'. In this way, links sent to mailing list, in the indexes, will be persistent over the years.
To my first point, a proposal of files will be - name_book.xml - will have structure of a book and include name.xml - name_chapter.xml - will have structure of a chapter and include name.xml (to investigate whether won't be same as name.xml) - name.xml - similar to what is now name.sgml -- details about author, editor, etc... and include the other files - name_admin.xml - will contain the documentation for administrators -- same as name_users.sgml, just the 'users' is a bit unclear and thought 'admin' might be better - name_devel.xml. and others will be added as needed
Cheers, Daniel
On 02/27/08 01:26, Edson wrote:
Hi, Daniel... Guys...
So let's try to draw a first to-do list, so that the work can begin...
1- Migrate the existing DOCs from SGML to XML format: I'm not a DocBook expert but Henning and I already changed some thoughts on this. What's not clear to me is if this is just a translation matter or also a diagramatic problem? Translation is some kind of direct work, while diagramatic requires a previous discussion.
2- Suppress and/or Agregate new DOCs: Clean-up empty files (with a sort of "no content") is require, since there information can be gatered elsewhere, but agregate new DOCs is a sort of "asking for problems" approach, so I would say that some skeleton/template has to be defined. This has to become before this agregation issue. But this arises a problem: wich is the best 'skeleton'? Which kind of documentation will be present? How to automate it?
So this two points brings: 1- Documentation structure Skeleton/Template; 2- Documents Skeleton/Template defining chapter and, maybe, minimum section contents, definition of origin (directly from code? From Doxygen?) and, most important, responsibilities; 3- XML Style that translate/implement this skeleton/templates; 4- Conversion of actual SGML format to some DocBook-XML format;
Each of this points should define a milestone by itself and its end it could be marked with IRC meeting where the results could be presented and discussed.
Please these are only thoughs... so fell free to add more points and/or point me wrongs approaches.
Edson
-----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: terça-feira, 26 de fevereiro de 2008 18:37 To: Edson Cc: openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
Hello,
On 02/26/08 22:27, Edson wrote:
Hi, Guys...
I finish the first clean-up of the documentation. It consisted by:
- remove all FAQ and DEVEL files considered empty in content (no content at all or just the default lines);
- remove of the <RevHistory>/</RevHistory> tag (and of course anything Between them);
- remove the comments at the EOF that beginned with "<!-- Keep this element at the end of the file";
Thanks, I believe we should think also the context of migrating to xml format. Anybody with some docbook xml experience? Hints, tips? I am investigating now the best way to migrate from sgml to xml.
If we are going to remove some file, add new ones, we need to have in mind the near future as well.
The attached file (in ZIP format) is the resulting SVN DIFF file. It was applied over trunk version, revision 3761.
I would like to ask the developers how much is a good time to wait for comments and revisions before commiting the changes? 1 week? 10 days? Sugestions?
Let's plan kind of to-do list/roadmap, to sync the work and check the milestones. Otherwise many will work on same task, or go totally different direction.
Cheers, Daniel
Edson
Openser-docs mailing list Openser-docs@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
On Wednesday 27 February 2008, Daniel-Constantin Mierla wrote:
your points are very good. It is the skeleton/template we have to define primary. Here I see couple of items you should take in consideration:
- ability to generate standalone readme per module and aggregate all in
single document. Perhaps here we can have two documets in each module, one that will have the head/tag of a book, and the other, head/tag of a chapter -- they will be very small, just including the other documents.
Hi Daniel, hi Edson,
your suggestions sounds good. Yes, it would be nice to generate a document containing all the module documentation. For this the existing 'set' docbook-xml tag could be used. This allows the combination of several books to one bigger compilation.
- module names, parameters name, function names, PV names, ..., must be
clearly marked so we can extract very easy the index. You did the previous indexes in dokuwiki, and you know better how hard is to do it with the current structure.
- the generated html formats should have all the time same anchor for
parameters, functions, a.s.o, so that the reference will stay the same, even new elements are introduced. If I am not wrong, that is possible by setting an unique 'id'. In this way, links sent to mailing list, in the indexes, will be persistent over the years.
If we have a unique id per chapter/ section, then this could be easily done. The whole id stuff is for example documented at: http://opensource.bureau-cornavin.com/crash-course/en/doc-structure.html
To my first point, a proposal of files will be
- name_book.xml - will have structure of a book and include name.xml
- name_chapter.xml - will have structure of a chapter and include
name.xml (to investigate whether won't be same as name.xml)
- name.xml - similar to what is now name.sgml -- details about author,
editor, etc... and include the other files
- name_admin.xml - will contain the documentation for administrators --
same as name_users.sgml, just the 'users' is a bit unclear and thought 'admin' might be better
- name_devel.xml. and others will be added as needed
Each file we add here increases the overhead for processing. And both of 'name_admin.xml' and 'name_devel.xml' are separate chapters anyway, so i don't think that we need the 'name_chapter.xml' file. And the "structure of a book" is not so complex, so i also think that we don't need a own file for this too. What do you think are the advantages in splitting this to discrete files?
Perhaps we can just stay with the actual structure? Then name.xml will contain the book definition, author and include the other files. The name_admin.xml file contains the user/ admin documentation, a name_devel.xml and other will be added over time. This would also ease the conversion process.
Cheers,
Henning
Hello,
On 02/27/08 14:15, Henning Westerholt wrote:
On Wednesday 27 February 2008, Daniel-Constantin Mierla wrote:
your points are very good. It is the skeleton/template we have to define primary. Here I see couple of items you should take in consideration:
- ability to generate standalone readme per module and aggregate all in
single document. Perhaps here we can have two documets in each module, one that will have the head/tag of a book, and the other, head/tag of a chapter -- they will be very small, just including the other documents.
Hi Daniel, hi Edson,
your suggestions sounds good. Yes, it would be nice to generate a document containing all the module documentation. For this the existing 'set' docbook-xml tag could be used. This allows the combination of several books to one bigger compilation.
great! Didn't know about.
- module names, parameters name, function names, PV names, ..., must be
clearly marked so we can extract very easy the index. You did the previous indexes in dokuwiki, and you know better how hard is to do it with the current structure.
- the generated html formats should have all the time same anchor for
parameters, functions, a.s.o, so that the reference will stay the same, even new elements are introduced. If I am not wrong, that is possible by setting an unique 'id'. In this way, links sent to mailing list, in the indexes, will be persistent over the years.
If we have a unique id per chapter/ section, then this could be easily done. The whole id stuff is for example documented at: http://opensource.bureau-cornavin.com/crash-course/en/doc-structure.html
section would be the hard one, as there are parameters with same name. Perhaps some patterns have to be defined here, like modulename_id. It is easier in this way to avoid conflicts with other modules.
To my first point, a proposal of files will be
- name_book.xml - will have structure of a book and include name.xml
- name_chapter.xml - will have structure of a chapter and include
name.xml (to investigate whether won't be same as name.xml)
- name.xml - similar to what is now name.sgml -- details about author,
editor, etc... and include the other files
- name_admin.xml - will contain the documentation for administrators --
same as name_users.sgml, just the 'users' is a bit unclear and thought 'admin' might be better
- name_devel.xml. and others will be added as needed
Each file we add here increases the overhead for processing. And both of 'name_admin.xml' and 'name_devel.xml' are separate chapters anyway, so i don't think that we need the 'name_chapter.xml' file. And the "structure of a book" is not so complex, so i also think that we don't need a own file for this too. What do you think are the advantages in splitting this to discrete files?
name_chapter.xml was just the main file for the case when the aggregated book was generated. I had no real expertise to know whether we can combine docbooks in another docbook. My idea was, when generating stand alone readme, use name_book.xml. For the aggregated readme, there should be some master file that will include all "name_chapter.xml" files. Once again, it may not be required, as you said.
As I had it in mind, a name_book.xml would be (pseudocode) <book> include here name_chapter.xml </book>
The name_chapter would be <chapter> include here name_admin.xml </chapter>
Perhaps we can just stay with the actual structure? Then name.xml will contain the book definition, author and include the other files. The name_admin.xml file contains the user/ admin documentation, a name_devel.xml and other will be added over time. This would also ease the conversion process.
yes, all ok for me.
Cheers, Daniel
Cheers,
Henning
On Tuesday 26 February 2008, Edson wrote:
I finish the first clean-up of the documentation. It consisted by:
- remove all FAQ and DEVEL files considered empty in content (no content at all or just the default lines);
- remove of the <RevHistory>/</RevHistory> tag (and of course anything Between them);
- remove the comments at the EOF that beginned with "<!-- Keep this element at the end of the file";
The attached file (in ZIP format) is the resulting SVN DIFF file. It was applied over trunk version, revision 3761.
I would like to ask the developers how much is a good time to wait for comments and revisions before commiting the changes? 1 week? 10 days?
Hi Edson,
thank you. I think i will apply your patch later today, if there is no oposition to this.
Step 2) and 3) are not user visible at all, for 1) i don't think that anybody will miss the empty developer documentation. For the FAQ it would perhaps sense to just include a standard document from a central place, e.g. the docs directory.
Cheers,
Henning
On Tuesday 26 February 2008, Edson wrote:
I finish the first clean-up of the documentation. It consisted by:
- remove all FAQ and DEVEL files considered empty in content (no content at all or just the default lines);
- remove of the <RevHistory>/</RevHistory> tag (and of course anything Between them);
- remove the comments at the EOF that beginned with "<!-- Keep this element at the end of the file";
The attached file (in ZIP format) is the resulting SVN DIFF file. It was applied over trunk version, revision 3761.
Hi Edson,
i've applied your changes to the svn trunk. There were some issues with the patch on my checkout, so i used the script that you've send me yesterday. ;-)
Anyway, with this changes the module documentation don't build anymore, because the faq and devel files are missing. I guess that should be fixed. :-)
I the header of each files there are the entities defined:
<!ENTITY user SYSTEM "maxfwd_user.sgml"> <!ENTITY devel SYSTEM "maxfwd_devel.sgml"> <!ENTITY faq SYSTEM "maxfwd_faq.sgml">
And on the bottom there included:
&user; &devel; &faq;
For all modules that don't define a own devel file the define and include for that should be removed. And for all files that don't define a own faq file, for the define the new copy on "../../../doc/module_faq.sgml" should be used. This way the empty devel section will be removed from most modules documentation, and the FAQ sections will stays the same. What do you think about this?
There is also a additional issue with the <RevHistory> stuff you removed. This were included in a <chapterinfo></chapterinfo> block. Apparently an empty block like this is not valid, so i think the empty <chapterinfo> must also be removed.
You're quite good with this scripting stuff, perhaps you can take a look?
Thank you,
Henning
Sure, Henning...
I detect the same problem in DOC compilation... I'll take a look in Your suggestions and make the necessary changes on the scripts... after that I'll re-send them to You so that You can apply them... ;)
I thing that the issues that You faced, on applying the patch, were due the fact that they use portuguese messages (I 'm just guessing... ;) )
In fact, if any of the other guys in this list could point more of this "general clean-up rules", please, let me know so that I can make scripts to apply than in a more automated way.
Edson
-----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: quarta-feira, 27 de fevereiro de 2008 11:20 To: openser-docs@lists.openser.org Cc: Edson Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Tuesday 26 February 2008, Edson wrote:
I finish the first clean-up of the documentation. It consisted by:
- remove all FAQ and DEVEL files considered empty in content (no content at all or just the default lines);
- remove of the <RevHistory>/</RevHistory> tag (and of course anything Between them);
- remove the comments at the EOF that beginned with "<!-- Keep this element at the end of the file";
The attached file (in ZIP format) is the resulting SVN DIFF file. It was applied over trunk version, revision 3761.
Hi Edson,
i've applied your changes to the svn trunk. There were some issues with the patch on my checkout, so i used the script that you've send me yesterday. ;-)
Anyway, with this changes the module documentation don't build anymore, because the faq and devel files are missing. I guess that should be fixed. :-)
I the header of each files there are the entities defined:
<!ENTITY user SYSTEM "maxfwd_user.sgml">
<!ENTITY devel SYSTEM "maxfwd_devel.sgml">
<!ENTITY faq SYSTEM "maxfwd_faq.sgml">
And on the bottom there included:
&user; &devel; &faq;
For all modules that don't define a own devel file the define and include for that should be removed. And for all files that don't define a own faq file, for the define the new copy on "../../../doc/module_faq.sgml" should be used. This way the empty devel section will be removed from most modules documentation, and the FAQ sections will stays the same. What do you think about this?
There is also a additional issue with the <RevHistory> stuff you removed. This were included in a <chapterinfo></chapterinfo> block. Apparently an empty block like this is not valid, so i think the empty <chapterinfo> must also be removed.
You're quite good with this scripting stuff, perhaps you can take a look?
Thank you,
Henning
On Wednesday 27 February 2008, Edson wrote:
Sure, Henning...
I detect the same problem in DOC compilation... I'll take a look in Your suggestions and make the necessary changes on the scripts... after that I'll re-send them to You so that You can apply them... ;)
I thing that the issues that You faced, on applying the patch, were due the fact that they use portuguese messages (I 'm just guessing... ;) )
In fact, if any of the other guys in this list could point more of this "general clean-up rules", please, let me know so that I can make scripts to apply than in a more automated way.
Hi Edson,
any news with this issue? I already did some changes manually for the carrierroute and userblacklist documentation, if you want to compare with the solution you've created..
Cheers,
Henning
Hi, Guys... Henning...
Sorry for the delay... I was busy... :(
I already send Henning a new version of a script that (as far as I could test), applied to the last SVN will recover the DOC compilation...
The introduced changes are: - Clear of lost <chapterinfo>,</chapterinfo> pair of tags; - Clear unneeded <!ENTITY ...> tags and reference;
Please, if You find anything wrong, please (again...;) ) let me know.
Thanks for Your patience,
Edson
-----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: segunda-feira, 3 de março de 2008 10:16 To: Edson Cc: openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Wednesday 27 February 2008, Edson wrote:
Sure, Henning...
I detect the same problem in DOC compilation... I'll take a look in Your suggestions and make the necessary changes on the scripts... after that I'll re-send them to You so that You can apply them... ;)
I thing that the issues that You faced, on applying the patch, were due
the
fact that they use portuguese messages (I 'm just guessing... ;) )
In fact, if any of the other guys in this list could point more of this "general clean-up rules", please, let me know so that I can make scripts
to
apply than in a more automated way.
Hi Edson,
any news with this issue? I already did some changes manually for the carrierroute and userblacklist documentation, if you want to compare with the solution you've created..
Cheers,
Henning
On Monday 03 March 2008, Edson wrote:
Hi, Guys... Henning...
Sorry for the delay... I was busy... :(
I already send Henning a new version of a script that (as far as I could test), applied to the last SVN will recover the DOC compilation...
The introduced changes are:
- Clear of lost <chapterinfo>,</chapterinfo> pair of tags;
- Clear unneeded <!ENTITY ...> tags and reference;
Hi Edson,
thank you for the patch, i applied it to trunk.
Cheers,
Henning
Danke Henning...
Please did You confirm that, at least Your modules compile correctly the README? Other developers???
Edson.
-----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: terça-feira, 4 de março de 2008 10:17 To: openser-docs@lists.openser.org Cc: Edson Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Monday 03 March 2008, Edson wrote:
Hi, Guys... Henning...
Sorry for the delay... I was busy... :(
I already send Henning a new version of a script that (as far as I could test), applied to the last SVN will recover the DOC compilation...
The introduced changes are:
- Clear of lost <chapterinfo>,</chapterinfo> pair of tags;
- Clear unneeded <!ENTITY ...> tags and reference;
Hi Edson,
thank you for the patch, i applied it to trunk.
Cheers,
Henning
On Tuesday 04 March 2008, Edson wrote:
Danke Henning...
Please did You confirm that, at least Your modules compile correctly the README? Other developers???
Hi Edson,
i checked that before commiting, and at least on my svn checkout it generates now. Do you observed some problems on your installation?
Cheers,
Henning
No... but... prevention is never a waste of time.... ;)
Edson.
-----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: terça-feira, 4 de março de 2008 13:16 To: Edson Cc: openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Tuesday 04 March 2008, Edson wrote:
Danke Henning...
Please did You confirm that, at least Your modules compile correctly the README? Other developers???
Hi Edson,
i checked that before commiting, and at least on my svn checkout it generates now. Do you observed some problems on your installation?
Cheers,
Henning
On 03/04/08 18:49, Edson wrote:
No... but... prevention is never a waste of time.... ;)
so, now, what is the next step to migrate to xml?
Edson, would you write a script to: - replace the sgml header with xml one - rename the extension from sgml to xml - update the references to modulename_user.xml, ..., inside the modulename.xml
If you will send the script to me, I will take care of fixing broken tags in sgml to become compliant with xml.
Should we rename modulename_user.xml to modulename_admin.xml?
I will work in updating the Makefile to generate txt/html/... from xml.
Cheers, Daniel
Edson.
-----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: terça-feira, 4 de março de 2008 13:16 To: Edson Cc: openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Tuesday 04 March 2008, Edson wrote:
Danke Henning...
Please did You confirm that, at least Your modules compile correctly the README? Other developers???
Hi Edson,
i checked that before commiting, and at least on my svn checkout it generates now. Do you observed some problems on your installation?
Cheers,
Henning
Openser-docs mailing list Openser-docs@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
Ok, Daniel...
Just now I'm a little busy here, but I think that I can have the script ready for tomorrow... When ready I'll send it to You...
Just a doubt: after reading Henning e-mail, are Your 'instructions' still correct, or should I change the "<!ENTITY" tag by another thing? Henning is this "<!ENTITY" tag ok for now, or do You have another sugestion?
Edson.
-----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: terça-feira, 4 de março de 2008 14:07 To: Edson Cc: 'Henning Westerholt'; openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On 03/04/08 18:49, Edson wrote:
No... but... prevention is never a waste of time.... ;)
so, now, what is the next step to migrate to xml?
Edson, would you write a script to:
- replace the sgml header with xml one
- rename the extension from sgml to xml
- update the references to modulename_user.xml, ..., inside the
modulename.xml
If you will send the script to me, I will take care of fixing broken tags in sgml to become compliant with xml.
Should we rename modulename_user.xml to modulename_admin.xml?
I will work in updating the Makefile to generate txt/html/... from xml.
Cheers, Daniel
Edson.
-----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: terça-feira, 4 de março de 2008 13:16 To: Edson Cc: openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Tuesday 04 March 2008, Edson wrote:
Danke Henning...
Please did You confirm that, at least Your modules compile correctly
the
README? Other developers???
Hi Edson,
i checked that before commiting, and at least on my svn checkout it generates now. Do you observed some problems on your installation?
Cheers,
Henning
Openser-docs mailing list Openser-docs@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
Thanks Edson, for me is ok to stick to ENTITY for now. I have to ask you to make an update to the docbook version in the xml files header -- in my example was 4.2, Henning discovered that 4.4 is the version shipped with Debian stable, please use that.
Cheers, Daniel
On 03/04/08 19:16, Edson wrote:
Ok, Daniel...
Just now I'm a little busy here, but I think that I can have the script ready for tomorrow... When ready I'll send it to You...
Just a doubt: after reading Henning e-mail, are Your 'instructions' still correct, or should I change the "<!ENTITY" tag by another thing? Henning is this "<!ENTITY" tag ok for now, or do You have another sugestion?
Edson.
-----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: terça-feira, 4 de março de 2008 14:07 To: Edson Cc: 'Henning Westerholt'; openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On 03/04/08 18:49, Edson wrote:
No... but... prevention is never a waste of time.... ;)
so, now, what is the next step to migrate to xml?
Edson, would you write a script to:
- replace the sgml header with xml one
- rename the extension from sgml to xml
- update the references to modulename_user.xml, ..., inside the
modulename.xml
If you will send the script to me, I will take care of fixing broken tags in sgml to become compliant with xml.
Should we rename modulename_user.xml to modulename_admin.xml?
I will work in updating the Makefile to generate txt/html/... from xml.
Cheers, Daniel
Edson.
-----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: terça-feira, 4 de março de 2008 13:16 To: Edson Cc: openser-docs@lists.openser.org Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Tuesday 04 March 2008, Edson wrote:
Danke Henning...
Please did You confirm that, at least Your modules compile correctly
the
README? Other developers???
Hi Edson,
i checked that before commiting, and at least on my svn checkout it generates now. Do you observed some problems on your installation?
Cheers,
Henning
Openser-docs mailing list Openser-docs@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
On Tuesday 04 March 2008, Edson wrote:
Ok, Daniel...
Just now I'm a little busy here, but I think that I can have the script ready for tomorrow... When ready I'll send it to You...
Just a doubt: after reading Henning e-mail, are Your 'instructions' still correct, or should I change the "<!ENTITY" tag by another thing? Henning is this "<!ENTITY" tag ok for now, or do You have another sugestion?
Hi all,
sorry, don't want to introduce further confusion. I found a good tutorial about the xinclude stuff [1], and i now think that we should go directly for the xinclude. Its not that complicated i think.
Basically it boils down to a few changes in $name.sgml:
- add some string (a namespace identifier) to the book tag, e.g. <book xmlns:xi="http://www.w3.org/2001/XInclude">
- and replace the &devel, &user.. references with:
<xi:include href="acc_faq.sgml"/> <xi:include href="acc_user.sgml"/>
- and perhaps adding the --xinclude config switch to the xsltproc call, but i think i don't do this for the db scheme stuff, at least i don't remember. ;-)
Cheers,
Henning
On Tuesday 04 March 2008, Henning Westerholt wrote:
<xi:include href="acc_faq.sgml"/> <xi:include href="acc_user.sgml"/>
This of course only apply to the acc module, basically just the filename that is used in the ENTITY on top of the file should be included here. It works the same way like a normal HTTP href.. :)
Henning
-
Daniel-Constantin Mierla -
Edson -
Henning Westerholt