You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Patrik Grip-Jansson <pa...@gnulix.org> on 2002/02/27 01:59:19 UTC

XML/XSLT/And so on...

I was toying around with manual.xls a bit. I tried running it through the 
C++ versions of xerces and xalan, and I discovered that there are some 
small problems with the transforms. I think I've ironed out the problems, 
and they still seems to be working with the usual browsers.

Secondly, I was thinking; wouldn't it be a good idea to internationalize 
manual.xsl? What few words there are could easily be applied on the fly.

Thirdly, the html-output isn't all that nice looking. It's a mixture of 
HTML versions and techniques. Why not consolidate it all to a good solid 
CSS/XHTML fundation? While still making sure that it is readable/accesible 
on legacy browsers.

If no one objects, I wouldn't mind fixing up manual.xls.

I think we need to discuss the choosen XML markup keywords a bit further. 
How to use it in text, how to validate it, how to translate it (for 
various output sources). I guess this ties in with the discussions earlier 
on.

-- 
.---------------------.
| Patrik Grip-Jansson |
| Ringen 4B           |    .--------------------.
| 78444 Borlänge   .--'----' http://gnulix.com/ `---------.
| Sweden           |  All views and opinions are my own,  |
`------------------| PH:+46(0)24382823 PW:+46(0)707354360 |
                   `--------------------------------------'


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Re: XML/XSLT/And so on...

Posted by Joshua Slive <jo...@slive.ca>.

On Wed, 27 Feb 2002, Patrik Grip-Jansson wrote:

> I was toying around with manual.xls a bit. I tried running it through the
> C++ versions of xerces and xalan, and I discovered that there are some
> small problems with the transforms. I think I've ironed out the problems,
> and they still seems to be working with the usual browsers.

Great.  Please also make sure it works in the java versions.  I wrote
manual.xsl and it was the first xsl I've ever tried.  I'm sure it could be
much improved.  Note that I made some changes in it today, so if you are
working on an older version, please make sure the new stuff gets
incorporated.  When you have something you like, post it to the list and
we will review/apply it for you.

>
> Secondly, I was thinking; wouldn't it be a good idea to internationalize
> manual.xsl? What few words there are could easily be applied on the fly.

Yes.  But I'm not sure what is the best way to approach this.
Conceivably, we could have mod_setenvif.xml.en, mod_setenvif.xml.fr, etc,
and we would want to transform those into mod_setenvif.html.en,
mod_setenvif.html.fr, etc.  Making that happen will take some change to
the stylesheet and/or changes to the build system.  The build system is
currently ant, but I'm not wedded to that.  Whatever is the most simple
and functional.

>
> Thirdly, the html-output isn't all that nice looking. It's a mixture of
> HTML versions and techniques. Why not consolidate it all to a good solid
> CSS/XHTML fundation? While still making sure that it is readable/accesible
> on legacy browsers.

+1.  The current html is just a hack job / proof of concept.  I have no
attachment to it.  If you can improve it (and I'm sure you can), fire
away.  Just please try to stick to an overall simple and clean look.

>
> If no one objects, I wouldn't mind fixing up manual.xls.
>
> I think we need to discuss the choosen XML markup keywords a bit further.
> How to use it in text, how to validate it, how to translate it (for
> various output sources). I guess this ties in with the discussions earlier
> on.

Yes.  There are a number of ways to approach this.  One choice would be
for me to spend some time adding more detail to
http://httpd.apache.org/docs-project/docsformat.html
Another approach is for you to just start asking some questions on the
list, and we can flush it out that way.  What do you think would work
best?

Joshua.


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org