Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@httpd.apache.org
Date: Fri, 17 May 2002 17:38:23 -0400 (Eastern Daylight Time)
From: Joshua Slive <joshua@slive.ca>
To: <docs@httpd.apache.org>
Subject: Re: Antwort: Re: cvs commit: httpd-2.0/docs/manual/style build.xml
In-Reply-To: <C1256BBC.00658885.00@detkw004.dnotes.telekurs.com>
Message-ID: <Pine.WNT.4.33.0205171727450.-1865127-100000@jgcomputer>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Fri, 17 May 2002 Michael.Schroepl@telekurs.com wrote:
> I somehow lost the exact problem specification.

Perhaps we all have.

> So I have to play some guessing game:
>
> a) The XML files need distinct file names for language
>    variants - but are _they_ language negotiated by
>    anyone? Will they be shipped with Apache as well, or
>    are they just the "holy internal representation"?

The important thing right now is that the html files are negotiable, but I
think we should retain the ability to negotiate properly with the xml if
we can.

>
> b) "ant" is intended to be used for transforming XML to
>    HTML, and the language extension must not get lost
>    during this process. But has the result to already
>    be negotiable without any further transformation?
>
> c) Which process is invoking the XML -> HTML transforma-
>    tion? Will this be done manually, or would there be
>    some Makefile to transform all the XMLs to HTMLs?

Ant is essentially the java version of make.  It calls Xalan-J to do the
actual xslt magic.  The problem is that when ant supplies the output
filename to Xalan, it doesn't consider the case of multiple file
extensions -- it simply replaces the last extension with "html".  Since we
need the last extension to be the language tag, the result is garbage.

There are lots of potential solutions to this problem, but none is
particularly nice.  The two closest I see right now:

1. Start enforcing the "no extension" rule in the apache docs -- ie.,
refer to files as mod/suexec with no extension.  I don't think this is a
particularly good idea right now because it would break a ton of links and
because it would introduce xml/html into the negotiation mix -- we might
want that at some point, but not until we have properly researched it.

2. Abandon ant and require the use of gnumake.  Here we lose a bunch of
nice features like style-sheet preloading.  It would perhaps be nice to
abandon java entirely and go with Xalan-C, but from my limited testing,
that version won't even touch the japanese encoding, so we'd be stuck
with a mixed environment.

I'll probably go with 2.

Joshua.


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