You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by André Malo <nd...@perlig.de> on 2002/12/15 23:19:49 UTC
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
* erikabele@apache.org wrote:
> +<!-- Character mnemonic entities -->
> +
> +<!ENTITY % HTMLlat1 PUBLIC
> + "-//W3C//ENTITIES Latin 1 for XHTML//EN"
> + "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent">
[...]
ehm... shouldn't this be
<!ENTITY % HTMLlat1 SYSTEM "w3c/xhtml-lat1.ent">
and so on?
Another question: How can we use the xhtml dtds to validate our html files?
nd
--
Treat your password like your toothbrush. Don't let anybody else
use it, and get a new one every six months. -- Clifford Stoll
(found in ssl_engine_pphrase.c)
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by André Malo <nd...@perlig.de>.
* Erik Abele wrote:
>> i.e. the commandline options
>>
>> -Xmx128m -mx128m
>>
>> set the stack size to 128K instead of 64 (default in newer java machines,
>> at least on win32). found this on the xalan pages (I believe).
>
> Ahh, interesting; didn't know that, but will try tomorrow. Perhaps this
> will eleminate some other problems I had with this machine ;-)
oops. meant 128_M_ ...
nd
--
s;.*;aaaaaoaaaoaaaaooooaaoaaaomaaaa:a:alataa:aaoat:a:a:a
maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa
matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:;
\40\51/\134\137|ndparker <nd...@perlig.de>;;print;
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by Erik Abele <er...@codefaktor.de>.
André Malo wrote:
> * Erik Abele wrote:
>
>
>>To quote you from another mail on the dev@ list: 'A feature that can't be
>>disabled is a *bug*' (Message-ID:
>><n2...@news.perlig.de>). Therefore, I consider this
>>definitely as a bug ;-)
>
> ehm, yes ;-)
> *mumblesomething*
hehe ;-)
>
>
>>>However. I'm not happy with that solution, since it adds a dependency to
>>>the process that is (currently) not needed. If we consider sometime not to
>>>distribute the entity files (that are only required for the transformation
>>>process), we may simply re-add the stuff, that's now in.
>>>The .dtds are already referenced absolute and with publicId, so there's no
>>>problem.
>>
>>Well, I'm going fine with this; we don't _need_ it now, that's right, but I
>>just can't see how 8 (?) lines complicate the build process so much and IMO
>>'foreign' resources should be referenced to their original source instead of
>>referencing them with local copies, but that's more a personal thing...
>
>
> Hmm. seems really to be a question of taste. So I'm putting a +/- 0 ;-)
To be really honest: this might not the best possible solution for
everybody, but I don't see it doing any harm, so +/- 0 from me too ;-)
>>However, another more important concern is Ants memory usage. After playing
>>with some entities I realized strong problems: just randomly touch some
>>files in the manual dir and add some entities (e.g. ©) to some of them.
>>Then build. I'm always getting OutOfMemory failures and can only build the
>>whole tree after calling build.sh several times. I don't know if it's
>>machine-dependent (I can currently build only on redhat8.0, P4/128MB, will
>>test it later with 1GB RAM on freebsd) but I would like to hear some other
>>experiences with this. Perhaps the conclusion is, that we have to back out
>>the whole entity-thing :-(
>
>
> Cannot reproduce it with first tests. But this may be dependant on my
> "optimized" java call. I increased the thread stack size already some time
> ago (while playing around with design improvements...)
>
fine, sounds good. I also couldn't recreate the mentioned problems on my
home machine...
> i.e. the commandline options
>
> -Xmx128m -mx128m
>
> set the stack size to 128K instead of 64 (default in newer java machines,
> at least on win32). found this on the xalan pages (I believe).
Ahh, interesting; didn't know that, but will try tomorrow. Perhaps this
will eleminate some other problems I had with this machine ;-)
cheers,
erik
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by André Malo <nd...@perlig.de>.
* Erik Abele wrote:
>> The mozilla bug is not really a bug. AFAICS it's intended. mozilla loads
>> external documents only from urls that use the chrome: scheme.
>> Unfortunately I don't find the url again, where I read this ;-(
>
> To quote you from another mail on the dev@ list: 'A feature that can't be
> disabled is a *bug*' (Message-ID:
> <n2...@news.perlig.de>). Therefore, I consider this
> definitely as a bug ;-)
ehm, yes ;-)
*mumblesomething*
>> However. I'm not happy with that solution, since it adds a dependency to
>> the process that is (currently) not needed. If we consider sometime not to
>> distribute the entity files (that are only required for the transformation
>> process), we may simply re-add the stuff, that's now in.
>> The .dtds are already referenced absolute and with publicId, so there's no
>> problem.
>
> Well, I'm going fine with this; we don't _need_ it now, that's right, but I
> just can't see how 8 (?) lines complicate the build process so much and IMO
> 'foreign' resources should be referenced to their original source instead of
> referencing them with local copies, but that's more a personal thing...
Hmm. seems really to be a question of taste. So I'm putting a +/- 0 ;-)
> However, another more important concern is Ants memory usage. After playing
> with some entities I realized strong problems: just randomly touch some
> files in the manual dir and add some entities (e.g. ©) to some of them.
> Then build. I'm always getting OutOfMemory failures and can only build the
> whole tree after calling build.sh several times. I don't know if it's
> machine-dependent (I can currently build only on redhat8.0, P4/128MB, will
> test it later with 1GB RAM on freebsd) but I would like to hear some other
> experiences with this. Perhaps the conclusion is, that we have to back out
> the whole entity-thing :-(
Cannot reproduce it with first tests. But this may be dependant on my
"optimized" java call. I increased the thread stack size already some time
ago (while playing around with design improvements...)
i.e. the commandline options
-Xmx128m -mx128m
set the stack size to 128K instead of 64 (default in newer java machines,
at least on win32). found this on the xalan pages (I believe).
However, the memory usage was about the same with or without some randomely
disitributed ©s (~ 100 K RAM).
it's a Win2k/Duron 1000/384KB box.
> Well, I've no problem with using   :-) Thoughts???
since it's not an entity.
nd
--
s s^saaaaaoaaaoaaaaooooaaoaaaomaaaa a alataa aaoat a a
a maoaa a laoata a oia a o a m a o alaoooat aaool aaoaa
matooololaaatoto aaa o a o ms;s;\s;s;g;y;s;:;s;y#mailto: #
\51/\134\137| http://www.perlig.de #;print;# > nd@perlig.de
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by André Malo <nd...@perlig.de>.
* André Malo wrote:
> currently the transformation process doesn't care about
> the catalog and loads the entities from the w3. (ISDN, not very funny).
*argh* my fault. I didn't update the w3c directory in the 2.0 branch. the
processor was clever enough to load it from the web then...
nd
--
> [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet?
DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da
so reinpacken und dann absolut positionieren ...
-- Florian Hartig und Lars Kasper in dciwam
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by Erik Abele <er...@codefaktor.de>.
> * Erik Abele wrote:
>
>> Okay, you're partially right :-) There is another, not so obvious
>> advantage with this: if we consider direct usage of the XML docs in the
>> future and forget about the ridiculous Mozilla bug, we don't need to
>> distribute the entity and DTD files (.ent/.dtd) later on, since they are
>> referenced with their PUBLIC identifier. We just 'fake' the online
>> references while building the XHTML files so there is no need to fetch
>> these files on every build. This is just for our convenience ;-) The
>> online XML docs are still referenced to the (always up-to-date)
>> resources, as they should IMO.
>>
>> Well, since we're not using the XML docs directly up to now this is not
>> very important, but later on it can save resources...
>
> *hrm*. At first: currently the transformation process doesn't care about
> the catalog and loads the entities from the w3. (ISDN, not very funny).
This should be okay after correctly updating all the files, as seen in your
last mail...
> The mozilla bug is not really a bug. AFAICS it's intended. mozilla loads
> external documents only from urls that use the chrome: scheme.
> Unfortunately I don't find the url again, where I read this ;-(
To quote you from another mail on the dev@ list: 'A feature that can't be
disabled is a *bug*' (Message-ID:
<n2...@news.perlig.de>). Therefore, I consider this
definitely as a bug ;-)
> However. I'm not happy with that solution, since it adds a dependency to
> the process that is (currently) not needed. If we consider sometime not to
> distribute the entity files (that are only required for the transformation
> process), we may simply re-add the stuff, that's now in.
> The .dtds are already referenced absolute and with publicId, so there's no
> problem.
Well, I'm going fine with this; we don't _need_ it now, that's right, but I
just can't see how 8 (?) lines complicate the build process so much and IMO
'foreign' resources should be referenced to their original source instead of
referencing them with local copies, but that's more a personal thing...
However, another more important concern is Ants memory usage. After playing
with some entities I realized strong problems: just randomly touch some
files in the manual dir and add some entities (e.g. ©) to some of them.
Then build. I'm always getting OutOfMemory failures and can only build the
whole tree after calling build.sh several times. I don't know if it's
machine-dependent (I can currently build only on redhat8.0, P4/128MB, will
test it later with 1GB RAM on freebsd) but I would like to hear some other
experiences with this. Perhaps the conclusion is, that we have to back out
the whole entity-thing :-(
Well, I've no problem with using   :-) Thoughts???
> I think further, that the build process is our own. It references to some
> of our own dtds, that use "our own" entities (currently not really, I know,
> but it's the same argument, what happens in future?)
>
> hmm. Other opinions?
would be nice to hear some :-)
cheers,
Erik
>
> nd
> --
> print "Just Another Perl Hacker";
>
> # André Malo, <http://www.perlig.de/> #
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by André Malo <nd...@perlig.de>.
* Erik Abele wrote:
> Okay, you're partially right :-) There is another, not so obvious
> advantage with this: if we consider direct usage of the XML docs in the
> future and forget about the ridiculous Mozilla bug, we don't need to
> distribute the entity and DTD files (.ent/.dtd) later on, since they are
> referenced with their PUBLIC identifier. We just 'fake' the online
> references while building the XHTML files so there is no need to fetch
> these files on every build. This is just for our convenience ;-) The
> online XML docs are still referenced to the (always up-to-date)
> resources, as they should IMO.
>
> Well, since we're not using the XML docs directly up to now this is not
> very important, but later on it can save resources...
*hrm*. At first: currently the transformation process doesn't care about
the catalog and loads the entities from the w3. (ISDN, not very funny).
The mozilla bug is not really a bug. AFAICS it's intended. mozilla loads
external documents only from urls that use the chrome: scheme.
Unfortunately I don't find the url again, where I read this ;-(
However. I'm not happy with that solution, since it adds a dependency to
the process that is (currently) not needed. If we consider sometime not to
distribute the entity files (that are only required for the transformation
process), we may simply re-add the stuff, that's now in.
The .dtds are already referenced absolute and with publicId, so there's no
problem.
I think further, that the build process is our own. It references to some
of our own dtds, that use "our own" entities (currently not really, I know,
but it's the same argument, what happens in future?)
hmm. Other opinions?
nd
--
print "Just Another Perl Hacker";
# André Malo, <http://www.perlig.de/> #
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by Erik Abele <er...@codefaktor.de>.
André Malo wrote:
> * Erik Abele wrote:
>>André Malo wrote:
>
>
>>><!ENTITY % HTMLlat1 SYSTEM "w3c/xhtml-lat1.ent">
>>
>
>>No, we can use the Ant <xmlcatalog> type to catch the online references
>>and use the local copies for the build process; just look at build.xml...
>
>
> ok, I see. But, if we'd use the relative reference as above, we don't
> *need* the xmlcatalog for the transformation process. In that case this
> would keep the build.xml simpler, since we would use it only for
> validation. The <xmlcatalog> would also be shortened, since there only the
> xhtml dtds had to be referenced (just for the validation process - they
> could be moved into the validate-xhtml target then.)
>
> Or am I wrong here?
>
Okay, you're partially right :-) There is another, not so obvious
advantage with this: if we consider direct usage of the XML docs in the
future and forget about the ridiculous Mozilla bug, we don't need to
distribute the entity and DTD files (.ent/.dtd) later on, since they are
referenced with their PUBLIC identifier. We just 'fake' the online
references while building the XHTML files so there is no need to fetch
these files on every build. This is just for our convenience ;-) The
online XML docs are still referenced to the (always up-to-date)
resources, as they should IMO.
Well, since we're not using the XML docs directly up to now this is not
very important, but later on it can save resources...
>
>>>Another question: How can we use the xhtml dtds to validate our html files?
>>
>
>>Since we are not using HTML<=4.x we can easily validate all our files
>>;-) For details see build.xml
>
>
> the catalog does the trick, ok. tried it myself before the build.xml
> update... ;-)
>
> nd
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by André Malo <nd...@perlig.de>.
* Erik Abele wrote:
> André Malo wrote:
>> <!ENTITY % HTMLlat1 SYSTEM "w3c/xhtml-lat1.ent">
> No, we can use the Ant <xmlcatalog> type to catch the online references
> and use the local copies for the build process; just look at build.xml...
ok, I see. But, if we'd use the relative reference as above, we don't
*need* the xmlcatalog for the transformation process. In that case this
would keep the build.xml simpler, since we would use it only for
validation. The <xmlcatalog> would also be shortened, since there only the
xhtml dtds had to be referenced (just for the validation process - they
could be moved into the validate-xhtml target then.)
Or am I wrong here?
>> Another question: How can we use the xhtml dtds to validate our html files?
> Since we are not using HTML<=4.x we can easily validate all our files
> ;-) For details see build.xml
the catalog does the trick, ok. tried it myself before the build.xml
update... ;-)
nd
--
>kann mir jemand sagen, was genau @-Domains sind?
Ein Mythos. Ein Werbetrick. Verarsche. Nenn es wie du willst...
-- Alexandra Buss und Björn Höhrmann in dciwam
Re: cvs commit: httpd-2.0/docs/manual/style common.dtd
Posted by Erik Abele <er...@codefaktor.de>.
André Malo wrote:
> * erikabele@apache.org wrote:
>
>
>> +<!-- Character mnemonic entities -->
>> +
>> +<!ENTITY % HTMLlat1 PUBLIC
>> + "-//W3C//ENTITIES Latin 1 for XHTML//EN"
>> + "http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent">
>
> [...]
>
> ehm... shouldn't this be
>
> <!ENTITY % HTMLlat1 SYSTEM "w3c/xhtml-lat1.ent">
>
> and so on?
No, we can use the Ant <xmlcatalog> type to catch the online references
and use the local copies for the build process; just look at build.xml...
>
> Another question: How can we use the xhtml dtds to validate our html files?
>
> nd
XHTML files are only XML files plus some own DTD magic :-) Therefore we
can use the xml-validation task to check our generated XHTML files
against the corresponding DTDs (xhtml1-strict.dtd,
xhtml1-transitional.dtd). just like we do for our 'normal' XML files
with our own DTDs.
Since we are not using HTML<=4.x we can easily validate all our files
;-) For details see build.xml
cheers,
Erik