27 Feb
2008
27 Feb
'08
1:27 a.m.
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
27 Feb
27 Feb
2:37 a.m.
Hello,
On 02/26/08 22:27, Edson wrote:
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";
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
4:26 a.m.
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(a)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:
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";
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(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
>
2:20 p.m.
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(a)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:
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";
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(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
>
> 
4:34 p.m.
On Tuesday 26 February 2008, Edson wrote:
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?
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
5:15 p.m.
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
7:19 p.m.
On Tuesday 26 February 2008, Edson wrote:
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.
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
7:35 p.m.
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(a)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:
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.
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
10:11 p.m.
Hello,
On 02/27/08 14:15, Henning Westerholt wrote:
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.
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>
On Wednesday 27 February 2008, Daniel-Constantin
Mierla wrote:
great! Didn't know about.
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.
yes, all ok for me.
Cheers,
Daniel
Cheers,
Henning
3 Mar
3 Mar
6:16 p.m.
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
10:45 p.m.
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(a)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
4 Mar
4 Mar
6:17 p.m.
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
9:04 p.m.
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(a)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
9:15 p.m.
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
9:49 p.m.
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(a)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
10:06 p.m.
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(a)lists.openser.org
Subject: Re: [OpenSER-Docs] First Clean-up Patch for Documentation
On Tuesday 04 March 2008, Edson wrote:
_______________________________________________
Openser-docs mailing list
Openser-docs(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
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
10:16 p.m.
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(a)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(a)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(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
>
10:36 p.m.
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(a)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(a)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(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/openser-docs
>
>
10:40 p.m.
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
[1]: http://cafe.elharo.com/xml/xinclude/
10:43 p.m.
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
5906
days inactive
5913
days old
19 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Edson -
Henning Westerholt