Re: [PHP-DOC] cvs: phpdoc /fr/appendices migration.xml migration4.xml
Hey Damien, please fix your line-endings! (Didn't you receive the mails from Egon and me about it?) Derick On Thu, 18 Oct 2001, Damien Seguy wrote: dams Thu Oct 18 18:42:08 2001 EDT Modified files: /phpdoc/fr/appendices migration4.xml migration.xml Log: Added september update. synch with tree Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net -
[PHP-DOC] Directorio de Nit.s
Title: EMPRESAS - Base de datos con las 1 DIRECTORIO DE NITS - Base de datos con más de 427.000 registros de Empresas Colombianas con los campos de Nit, Razón Social, Dirección, Teléfono, Ciudad, Departamento, CIIU, Actividad Empresarial. LA APLICACION que maneja la base de datos permite hacer búsquedas simples o complejas por todos los campos, agrupa diferentes tipos de búsquedas, prepara e imprime reportes y rótulos. La aplicación es totalmente autónoma, es decir no necesita ningún software adicional para su total desempeño en Windows 95 o superior. PRESENTACION - Las bases de datos y la aplicación se entregan en un CD, que permite la auto-instalación. VALOR DEL CD - Col$250.000, los cuales se depositan en COLMENA en la cuenta de ahorros No. 0114500194215 a nombre de Directorio Nacional de Fax, copia de la consignación con las instrucciones de entrega favor enviarlas al Fax 6178102/6179073 Bogotá, el CD y la factura serán enviados al día siguiente vía Servientrega Nit´s - Tr. 51A No 123-01 Int. 10 - Tel. 6135184 - Fax 6178102/6179073 [EMAIL PROTECTED] - Bogotá Colombia Si desea ser removido de esta base de datos, responda a este mensaje indicando remover en el subject
[PHP-DOC] cvs: phpdoc /it/functions bc.xml
cucinatoFri Oct 19 04:18:42 2001 EDT Modified files: /phpdoc/it/functionsbc.xml Log: added bc italian translation Index: phpdoc/it/functions/bc.xml diff -u /dev/null phpdoc/it/functions/bc.xml:1.7 --- /dev/null Fri Oct 19 04:18:42 2001 +++ phpdoc/it/functions/bc.xml Fri Oct 19 04:18:42 2001 @@ -0,0 +1,307 @@ +?xml encoding=iso-8859-1? +!-- EN-Revision: 1.15 Maintainer: cucinato Status: ready -- + reference id=ref.bc + titleFunzioni Matematiche BCMath a precisione arbitraria/title + titleabbrevBC math/titleabbrev + + partintro + para +In PHP 4, queste funzioni sono disponibili solo se PHP egrave; configurato con +option role=configurelink +linkend=install.configure.enable-bcmath--enable-bcmath/link/option. +In PHP 4, queste funzioni sono disponibili solo se PHP non egrave; configurato +con +option role=configurelink +linkend=install.configure.disable-bcmath--disable-bcmath/link/option. + /para + note +para + A causa di modifiche alla licenza, la liberia BCMATH egrave; distribuita + separatamente dalla distribuzione standard dei sorgenti PHP. + Egrave; posibile scaricare l'archivio tar-gzippato presso la url: + ulink url=url.bcmath;url.bcmath;/ulink. Vedere il + file filenameREADME.BCMATH/filename nella distribuzione di PHP + per ulteriori informazioni. +/para + /note + /partintro + + refentry id=function.bcadd + refnamediv +refnamebcadd/refname +refpurposeSomma due numeri a precisione arbitraria/refpurpose + /refnamediv + refsect1 +titleDescrizione/title +funcsynopsis + funcprototype + funcdefstring functionbcadd/function/funcdef + paramdefstring parameterprimo operando/parameter/paramdef + paramdefstring parametersecondo operando/parameter/paramdef + paramdefint + parameteroptionalprecisione/optional/parameter + /paramdef + /funcprototype +/funcsynopsis +para + Somma il parameterprimo operando/parameter con il + parametersecondo operando/parameter e restituisce la somma sotto forma di + stringa. Il parametro opzionale parameterprecisione/parameter egrave; + utilizzato per impostare il numero di cifre dopo il punto decimale nel + risultato. +/para +para + Vedere anche functionbcsub/function. +/para + /refsect1 + /refentry + + refentry id=function.bccomp + refnamediv +refnamebccomp/refname +refpurposeConfronta due numeri a precisione arbitraria/refpurpose + /refnamediv + refsect1 +titleDescrizione/title +funcsynopsis + funcprototype + funcdefint functionbccomp/function/funcdef + paramdefstring parameterprimo operand/parameter/paramdef + paramdefstring parametersecondo operand/parameter/paramdef + paramdefint + parameteroptionalprecisione/optional/parameter + /paramdef + /funcprototype +/funcsynopsis +para + Confronta il parameterprimo operando/parameter e il + parametersecondo operando/parameter e restituisce il risultato sotto forma di + intero. Il parametro opzionale parameterprecisione/parameter egrave; + utilizzato per impostare il numero di cifre dopo il punto decimale che + verranno usate nel confronto. Il valore restituito grave; 0 se i due + operandi sono uguali. Se il parameterprimo operando/parameter + egrave; piugrave; grande del parametersecondo operando/parameter il + valore restituito egrave; +1 e se il parameterprimo operando/parameter + egrave; minore del parametersecondo operando/parameter il valore restituito + egrave; -1. +/para + /refsect1 + /refentry + + refentry id=function.bcdiv + refnamediv +refnamebcdiv/refname +refpurposeDivide due numeri a precisione arbitraria/refpurpose + /refnamediv + refsect1 +titleDescrizione/title +funcsynopsis + funcprototype + funcdefstring functionbcdiv/function/funcdef + paramdefstring parameterprimo operando/parameter/paramdef + paramdefstring parametersecondo operando/parameter/paramdef + paramdefint + parameteroptionalprecisione/optional/parameter + /paramdef + /funcprototype +/funcsynopsis +para + Divide il parameterprimo operando/parameter per il + parametersecondo operando/parameter e restituisce il risultato. Il + parametro opzionale parameterprecisione/parameter imposta il numero di cifre + dopo il punto decimale nel risultato. +/para +para + Vedere anche functionbcmul/function. +/para + /refsect1 + /refentry + + refentry id=function.bcmod + refnamediv +refnamebcmod/refname +refpurpose + Ricava il modulo di un numero a precisione arbitraria +/refpurpose + /refnamediv + refsect1 +titleDescrizione/title +funcsynopsis + funcprototype + funcdefstring functionbcmod/function/funcdef + paramdefstring parameteroperando/parameter/paramdef +
[PHP-DOC] cvs: phpdoc /it Translators
cucinatoFri Oct 19 04:26:42 2001 EDT Modified files: /phpdoc/it Translators Log: Updated Index: phpdoc/it/Translators diff -u phpdoc/it/Translators:1.56 phpdoc/it/Translators:1.57 --- phpdoc/it/Translators:1.56 Sun Oct 7 05:46:45 2001 +++ phpdoc/it/Translators Fri Oct 19 04:26:41 2001 @@ -78,8 +78,8 @@ apache.xml baldo A array.xml cucinatoT1.102 aspell.xml cucinatoT1.16 -bc.xml cucinatoA1.15 -bzip2.xml +bc.xml cucinatoT1.15 +bzip2.xml cucinatoA1.10 calendar.xml ccvs.xml classobj.xml
[PHP-DOC] cvs: phpdoc /it Translators
peruginiFri Oct 19 05:09:01 2001 EDT Modified files: /phpdoc/it Translators Log: Added appendices/commandline.xml Index: phpdoc/it/Translators diff -u phpdoc/it/Translators:1.57 phpdoc/it/Translators:1.58 --- phpdoc/it/Translators:1.57 Fri Oct 19 04:26:41 2001 +++ phpdoc/it/Translators Fri Oct 19 05:09:01 2001 @@ -49,6 +49,7 @@ variables.xml baldo A1.15 --- appendices -- aliases.xmlperuginiT1.12 +commandline.xml debugger.xml peruginiA escaping.xml history.xmlperuginiT1.5
Re: [PHP-DOC] hebrew translation ?
On October 16, 2001 05:03 am, Hojtsy Gabor wrote: Hi Shlomi, You should write to the PHP Documentation team ([EMAIL PROTECTED]) - they can provide you with more information. Good Luck! :) This was exactly what he has done :)) silly me ... :) Goba :) sheepish grin For some reason, I thought that this was PHP webmaster mail. Yikes. :) for some reason , i didn't notice this too anyway , 10x for the help . few last question (maybe) : in the READMEs i read that i should check if my language is supported by docbook stylesheets : b) Have you made sure that your language or glyph (lettering, font, or characters) is supported by the docbook stylesheets? where can i do that ? if it's not supported , what do i do ? write my own stylesheets ? hebrew is a right to left lang . is that a problem ? there are two main standarts for writing hebrew : iso-visual : iso 8859-8 logical : 1252 does it matter what i use ? i like better the logical .. it's less problematic ... Regards Shlomi Loubaton --- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [PHP-DOC] hebrew translation ?
Shlomi Loubaton wrote: in the READMEs i read that i should check if my language is supported by "docbook" stylesheets : " b) Have you made sure that your language or glyph (lettering, font, or characters) is supported by the docbook stylesheets? " where can i do that ? if it's not supported , what do i do ? write my own stylesheets ? You can ask at DocBook Applications list [EMAIL PROTECTED]. Maybe there will be some user experienced with using hebrew with DocBook hebrew is a right to left lang . is that a problem ? there are two main standarts for writing hebrew : iso-visual : iso 8859-8 logical : 1252 does it matter what i use ? i like better the logical .. it's less problematic ... You should check if Jade a JadeTeX are able to handle these encodings and RTL text-flow. - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz
[PHP-DOC] cvs: phpdoc /en/functions array.xml
hholzgraFri Oct 19 06:47:17 2001 EDT Modified files: /phpdoc/en/functionsarray.xml Log: small clarification regarding each() and reset() Index: phpdoc/en/functions/array.xml diff -u phpdoc/en/functions/array.xml:1.105 phpdoc/en/functions/array.xml:1.106 --- phpdoc/en/functions/array.xml:1.105 Wed Oct 17 17:17:35 2001 +++ phpdoc/en/functions/array.xml Fri Oct 19 06:47:17 2001 @@ -1,5 +1,5 @@ ?xml encoding=iso-8859-1? -!-- $Revision: 1.105 $ -- +!-- $Revision: 1.106 $ -- reference id=ref.array titleArray Functions/title titleabbrevArrays/titleabbrev @@ -2057,7 +2057,9 @@ para After functioneach/function has executed, the array cursor will be left on the next element of the array, or on the last - element if it hits the end of the array. + element if it hits the end of the array. You have to use + functionreset/function if you want to traverse the array + again using each. /para para See also functionkey/function, functionlist/function,
[PHP-DOC] cvs: phpdoc /en/appendices commandline.xml
damsFri Oct 19 11:02:38 2001 EDT Modified files: /phpdoc/en/appendices commandline.xml Log: no message Index: phpdoc/en/appendices/commandline.xml diff -u phpdoc/en/appendices/commandline.xml:1.1 phpdoc/en/appendices/commandline.xml:1.2 --- phpdoc/en/appendices/commandline.xml:1.1Sun Oct 14 09:19:12 2001 +++ phpdoc/en/appendices/commandline.xmlFri Oct 19 11:02:37 2001 @@ -1,5 +1,5 @@ ?xml encoding=iso-8859-1? -!-- $Revision: 1.1 $ -- +!-- $Revision: 1.2 $ -- !-- TODO: @@ -20,7 +20,7 @@ different purpose than web scripting. /para para - Note, that you can allways direct the output of the PHP + Note, that you can always direct the output of the PHP executable to an external file with the gt; character, so literalphp -q test.php test.html/literal will print out the output of filenametest.php/filename @@ -78,7 +78,7 @@ row entry-q/entry entry - Suppress HTTP headers output. Normally PHP prints out + Suppress HTTP headers output. Normaly PHP prints out HTTP headers for the calling program (ie. webserver) to hand on to the browser. When writing command line applications these headers are useless. @@ -215,7 +215,7 @@ In the program above we checked if there are less or more than one arguments. Also if the argument was literal--help/literal, literal-help/literal, literal-h/literal or literal-?/literal, - we printed out the help message, printng the script name dynamically. + we printed out the help message, printing the script name dynamically. If we received some other argument we echoed that out. /para para
[PHP-DOC] cvs: phpdoc /en/appendices commandline.xml
damsFri Oct 19 11:08:49 2001 EDT Modified files: /phpdoc/en/appendices commandline.xml Log: Correcting my own mistakes =D Index: phpdoc/en/appendices/commandline.xml diff -u phpdoc/en/appendices/commandline.xml:1.2 phpdoc/en/appendices/commandline.xml:1.3 --- phpdoc/en/appendices/commandline.xml:1.2Fri Oct 19 11:02:37 2001 +++ phpdoc/en/appendices/commandline.xmlFri Oct 19 11:08:49 2001 @@ -1,5 +1,5 @@ ?xml encoding=iso-8859-1? -!-- $Revision: 1.2 $ -- +!-- $Revision: 1.3 $ -- !-- TODO: @@ -78,7 +78,7 @@ row entry-q/entry entry - Suppress HTTP headers output. Normaly PHP prints out + Suppress HTTP headers output. Normally PHP prints out HTTP headers for the calling program (ie. webserver) to hand on to the browser. When writing command line applications these headers are useless.
[PHP-DOC] RFC
i have just uploaded the draft for the 'beyond' part of my conference talk The manual and beyond to http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf comments suggestions are highly appreciated :) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
Re: [PHP-DOC] RFC
i have just uploaded the draft for the 'beyond' part of my conference talk The manual and beyond to http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf comments suggestions are highly appreciated :) You should speak about - the problem of entities (global.ent) as used in some old translations and the main tree (deletes can make unbuildable manuals) - Jouni suggested to split up installation.xml also, as it is a hube beast now, and it is impossible to start the translation and finish it in a reasonable time (the same as with function files, mixed language). That is the most huge part, and there are some semi-sections (eg. Servers- prefix of titles), which are ugly IMHO, but with the current system, we can't do anything. - Extending docbook with namespaces. Also with drawbacks (design validity testing and other problems mentioned by Jirka). After reading the pdf through these things seemed to be important. Maybe more will come into my mind in the future. Goba
Re: [PHP-DOC] RFC
On Fri, 19 Oct 2001, Hartmut Holzgraefe wrote: i have just uploaded the draft for the 'beyond' part of my conference talk The manual and beyond to http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf comments suggestions are highly appreciated :) I really like the part 'Maybe its time to get invloved [typos not fixed] into the DocBook project itself, [...]' (Jirka actually is doing exactly that). If DocBook can't satisfy a programming projects' needs, someone is not modeling something the right way. Currently, I refuse to have any opinions about whether it's us or the team that defines DocBook. -- Jouni
[PHP-DOC] cvs: phpdoc /it/functions array.xml
cucinatoFri Oct 19 13:39:17 2001 EDT Modified files: /phpdoc/it/functionsarray.xml Log: small clarification regarding each() and reset() Index: phpdoc/it/functions/array.xml diff -u phpdoc/it/functions/array.xml:1.19 phpdoc/it/functions/array.xml:1.20 --- phpdoc/it/functions/array.xml:1.19 Thu Oct 18 09:25:50 2001 +++ phpdoc/it/functions/array.xml Fri Oct 19 13:39:17 2001 @@ -1,5 +1,5 @@ ?xml encoding=iso-8859-1? - !-- EN-Revision: 1.105 Maintainer: cucinato Status: ready -- + !-- EN-Revision: 1.106 Maintainer: cucinato Status: ready -- reference id=ref.array titleFunzioni di Array/title titleabbrevArrays/titleabbrev @@ -2057,7 +2057,9 @@ para Dopo l'esecuzione di functioneach/function, il puntatore dell'array viene lasciato sull'elemento successivo, o sull'ultimo - elemento se si egrave; alla fine dell'array. + elemento se si egrave; alla fine dell'array. Si deve utilizzare + functionreset/function se si vuole riattraversare l'array + usando functioneach/function. /para para Vedere anche functionkey/function, functionlist/function,
Re: [PHP-DOC] RFC
- Original Message - From: Hojtsy Gabor [EMAIL PROTECTED] To: Hartmut Holzgraefe [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 19, 2001 7:05 PM Subject: Re: [PHP-DOC] RFC i have just uploaded the draft for the 'beyond' part of my conference talk The manual and beyond to http://zugeschaut-und-mitgebaut.de/php/conference-talk.pdf comments suggestions are highly appreciated :) You should speak about - the problem of entities (global.ent) as used in some old translations and the main tree (deletes can make unbuildable manuals) If you speak from old translations, so translate the other languages yourself. - Extending docbook with namespaces. Also with drawbacks (design validity testing and other problems mentioned by Jirka). I have said that extending DocBook is not allwowed. After reading the pdf through these things seemed to be important. Maybe more will come into my mind in the future. I hope I can talk with Hartmut tomorrow about this PDF on our PHP user meeting in Stuttgart. -Egon
Re: [PHP-DOC] RFC
OK, it seems my words were not clear. So rewording. - the problem of entities (global.ent) as used in some old translations and the main tree (deletes can make unbuildable manuals) If you speak from old translations, so translate the other languages yourself. It is not that I would like to do all the translations. This is a problem (like the translation of function files), that need to be mentioned. This is not a negative grading of translators working on some xml files. It is a fact, that this is a problem. Please _do not_ see this as an attack. There are problems with those entities and so with links to nonexistent XML ids. These are problems that should be discussed. - Extending docbook with namespaces. Also with drawbacks (design validity testing and other problems mentioned by Jirka). I have said that extending DocBook is not allwowed. So reworded: using namespaces to define tags, and use them along DocBook tags. This is exaclty not extending DocBook, but defining a DTD for our custom elements and use those two DTDs (DocBook and PHPDoc) side-by-side. Although I am __not__ speaking of extending DocBook, there is a chapter about Customizing DocBook, in DocBook: The definitive Guide. This customizing is what Jirka is talking about. So for DocBook it is allowed. It is our job to decide, whether we choose customizing or another way. I am against customizing DocBook this way, so we are on the same side (and so Hartmut, as I can see in this PDF). Goba
Re: [PHP-DOC] RFC
From: Hojtsy Gabor [EMAIL PROTECTED] - the problem of entities (global.ent) as used in some old translations and the main tree (deletes can make unbuildable manuals) If you speak from old translations, so translate the other languages yourself. It is not that I would like to do all the translations. This is a problem (like the translation of function files), that need to be mentioned. This is not a negative grading of translators working on some xml files. It is a fact, that this is a problem. Please _do not_ see this as an attack. There are problems with those entities and so with links to nonexistent XML ids. These are problems that should be discussed. Oh I see, you have understand my problem. - Extending docbook with namespaces. Also with drawbacks (design validity testing and other problems mentioned by Jirka). I have said that extending DocBook is not allwowed. So reworded: using namespaces to define tags, and use them along DocBook tags. This is exaclty not extending DocBook, but defining a DTD for our custom elements and use those two DTDs (DocBook and PHPDoc) side-by-side. This may be a misinformation. With tags I am always reffering to elements. Please don´t touch them. Customization is another deal. Although I am __not__ speaking of extending DocBook, there is a chapter about Customizing DocBook, in DocBook: The definitive Guide. This customizing is what Jirka is talking about. So for DocBook it is allowed. I know that :) But what will do the rest of the committeres all over this world? It is our job to decide, whether we choose customizing or another way. I am against customizing DocBook this way, so we are on the same side (and so Hartmut, as I can see in this PDF). What do you mean with our? -Egon
Re: [PHP-DOC] RFC
So reworded: using namespaces to define tags, and use them along DocBook tags. This is exaclty not extending DocBook, but defining a DTD for our custom elements and use those two DTDs (DocBook and PHPDoc) side-by-side. This may be a misinformation. With tags I am always reffering to elements. Please don´t touch them. Customization is another deal. The Customizing DocBook section also deals with adding tags, to the DocBook DTD as I can remember. http://www.docbook.org/tdg/en/html/ch05.html#ch05-addelem I do not want to touch DocBook elements, nor customize DocBook this way. I said we maybe can make another DTD, with only defining our own tags, we would like to use along side by side with DocBook. As Jirka mentioned, this would not be too good as a design decision, and the files can get impossible to validate, so this is not the way today. Then the only thing left for me is to use the role= attribute for some custom usage. I do not want to modify the DocBook DTD. Although I am __not__ speaking of extending DocBook, there is a chapter about Customizing DocBook, in DocBook: The definitive Guide. This customizing is what Jirka is talking about. So for DocBook it is allowed. I know that :) But what will do the rest of the committeres all over this world? As Jirka said, as long as they use the DocBook DTDs from the phpdoc repositories dbxml directory, they can use tags added there. For other tools not dependant on this directory, there would be much-much more problems. There are some (IMHO not so elegant) solutions posted by Jirka, and I can understand what he is saying, but I do not like adding tags this way. It is our job to decide, whether we choose customizing or another way. I am against customizing DocBook this way, so we are on the same side (and so Hartmut, as I can see in this PDF). What do you mean with our? The member of the PHP Documentation Team. I use this wording as the people who are working in phpdoc, not just those listed on the frontpage. From now on in this letter, I will use we as you Egon and me. IMHO generally we are talking about the same things. We do not want to add tags to DocBook into the DTD, because several reasons. Some of these reasons are technical, some of these are just opinions. We do want to keep the XML files validateable. Goba
Re: [PHP-DOC] RFC
On Fri, 19 Oct 2001, Egon Schmid wrote: From: Hojtsy Gabor [EMAIL PROTECTED] So reworded: using namespaces to define tags, and use them along DocBook tags. This is exaclty not extending DocBook, but defining a DTD for our custom elements and use those two DTDs (DocBook and PHPDoc) side-by-side. This may be a misinformation. With tags I am always reffering to elements. Please don´t touch them. Customization is another deal. Just to note: we are actually not using any official DocBook... manual.xml says: !DOCTYPE book PUBLIC -//Norman Walsh//DTD DocBk XML V1.7//EN ./dbxml/docbookx.dtd [... etc , then, phpdoc/dbxml/docbookx.dtd starts with: !-- DocBk XML V3.1.7 DTD Copyright (C) 1998, 1999 Norman Walsh http://nwalsh.com/docbook/xml/ See COPYRIGHT for more information Please direct all questions and comments about this DTD to Norman Walsh, [EMAIL PROTECTED]. -- And then, when I went and poked around at http://www.docbook.org/, found this: XML DocBook XML 4.1.2 is the current XML version of DocBook. There are no official XML versions of DocBook prior to V4.0. Maybe it should be the time to find out what the current DTD actually is, and what it allows us to do? -- Jouni
Re: [PHP-DOC] RFC
Hojtsy Gabor wrote: These are problems that should be discussed. thats exactly the reason for me writing the PDF almost everything i mention in there has already been talked about on this list in some way without much work going on on it so i tried to summarize the identified problems and the possible solutions So reworded: using namespaces to define tags, and use them along DocBook tags. This is exaclty not extending DocBook, but defining a DTD for our custom elements and use those two DTDs (DocBook and PHPDoc) side-by-side. this topic came up after i had finished my first draft so it is not mentioned yet, but it definetly should be in there Although I am __not__ speaking of extending DocBook, there is a chapter about Customizing DocBook, in DocBook: The definitive Guide. This customizing is what Jirka is talking about. So for DocBook it is allowed. if we wouldn't mind cutting us off of other DocBook aware environments we could customize whatever we want we distribute the DTD anyway and the extensibility of the modular stylesheets allow as much costomization as we want to have we would have to call it something else but DocBook then, maybe PHPBook or so but as soon as we start changing the DTD it would probably become sort of pandoras box getting more and more a thing of its own ... It is our job to decide, whether we choose customizing or another way. I am against customizing DocBook this way, so we are on the same side (and so Hartmut, as I can see in this PDF). well, i tried to stay somehow neutral in this text, but customizing DocBook definetly comes for a price so the benefits we would gain from customizing do not compensate this for now IMHO
Re: [PHP-DOC] RFC
!DOCTYPE book PUBLIC -//Norman Walsh//DTD DocBk XML V1.7//EN ./dbxml/docbookx.dtd [... etc !-- DocBk XML V3.1.7 DTD Copyright (C) 1998, 1999 Norman Walsh http://nwalsh.com/docbook/xml/ See COPYRIGHT for more information Please direct all questions and comments about this DTD to Norman Walsh, [EMAIL PROTECTED]. -- DocBook XML 4.1.2 is the current XML version of DocBook. There are no official XML versions of DocBook prior to V4.0. Maybe it should be the time to find out what the current DTD actually is, and what it allows us to do? If we use 4.1.2 the official PUBLIC name for it is: -//OASIS//DTD DocBook XML V4.1.2//EN As projected in docbook.cat in the 4.1.2 package. So it is somewhat different than any other PUBLIC names, or DTDs we use. What a mess discovered! :) Goba
Re: [PHP-DOC] RFC
Jouni Ahto wrote: Maybe it should be the time to find out what the current DTD actually is, and what it allows us to do? very good point! (i was always refereing to the book which is for V3.1.x AFAIR)
Re: [PHP-DOC] RFC
Hojtsy Gabor wrote: As Jirka said, as long as they use the DocBook DTDs from the phpdoc repositories dbxml directory, they can use tags added there. For other tools not dependant on this directory, there would be much-much more problems. There are some (IMHO not so elegant) solutions I think that all tools are using DTD in dbxml directory because manual.xml starts with rather strange DOCTYPE: !DOCTYPE book PUBLIC "-//Norman Walsh//DTD DocBk XML V1.7//EN" "./dbxml/docbookx.dtd" [ FPI "-//Norman Walsh//DTD DocBk XML V1.7//EN" is referring to early Norm's play with transfering DocBook DTD from SGML to XML. Official FPI for DocBook XML DTD is -//OASIS//DTD DocBook XML V4.1.2//EN This should be changed. I don't expect that anyone would have earlier mentioned FPI in his catalog, so customizing DTD in dbxml directory shouldn't intact any processing tool. And please remember, I'm not suggesting you to customize nor not customize DTD. I just want to tell you, that customizing DTD doesn't bring as many troubles as you may think. BTW: From the lawyer's perspective of view, we are not using DocBook because currently used FPI is broken and doesn't associate with only official DocBook from OASIS. ;)) Jirka - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz
Re: [PHP-DOC] RFC
Jouni Ahto wrote: I really like the part 'Maybe its time to get invloved [typos not fixed] into the DocBook project itself, [...]' (Jirka actually is doing exactly that). If DocBook can't satisfy a programming projects' needs, someone is not modeling something the right way. Currently, I refuse to have any opinions about whether it's us or the team that defines DocBook. There is a standard way to request new feature for DocBook. You can submit new request at: https://sourceforge.net/tracker/?atid=384107group_id=21935func=browse But note that DocBook process is quite slow. Changes in DTD must be announced at least one major version before they are really implemented. So proposalf for something wouldn't be part of DocBook before version 6.0 (I don't think that this version would be published earlier than two years from now). So if there is a realy strong need for some new elements or small change in content models, customizing DTD is only way to do it now and in near future. Jirka - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz
Re: [PHP-DOC] RFC
On Fri, 19 Oct 2001, Hartmut Holzgraefe wrote: Jouni Ahto wrote: Maybe it should be the time to find out what the current DTD actually is, and what it allows us to do? very good point! (i was always refereing to the book which is for V3.1.x AFAIR) Besides, even if there's a clear need to change something, there's always the possibility of getting it accepted in the official version. See http://www.docbook.org/rfe/index.html http://sourceforge.net/tracker/?atid=384107group_id=21935func=browse -- Jouni
Re: [PHP-DOC] RFC
Hartmut Holzgraefe wrote: Jouni Ahto wrote: Maybe it should be the time to find out what the current DTD actually is, and what it allows us to do? very good point! (i was always refereing to "the book" which is for V3.1.x AFAIR) New version of TDG has actualised reference part for DocBook 4.1.2: http://www.docbook.org/tdg/en/html/docbook.html - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz
[PHP-DOC] Bug #12863 Updated: what does pg_freeresult return?
ID: 12863 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Open Status: Analyzed Bug Type: Documentation problem Operating System: PHP Version: 4.0.6 New Comment: I think (according to the source) it returns TRUE on success, FALSE on error. Can someone confirm this, and add it to the docs? Previous Comments: [2001-08-20 12:54:06] [EMAIL PROTECTED] The doc page for pg_freeresult does not state what the significance of the int return value is. Edit this bug report at http://bugs.php.net/?id=12863edit=1
