The error is: "filter-expr(funcall(current, []), [pred(=(step("attribute", 39), literal-expr(section)))])'. Cause: Erreur lors de la vérification du type de l'expression 'filter-expr(funcall(current, []), [pred(=(step("attribute", 39), literal-expr(section)))])"
This takes us 1 step closer to use Ant 1.9+ and remove Xerces and Xalan from the build chain.
Patch tested with the current doc build chain (Ant 1.6.5 + Xerces + Xalan) on the 2.4.x branch.
Even if actually we don't have any "<Foo>" and "Foo" directives, I've checked that the doc is built correctly in such a case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1854677 13f79535-47bb-0310-9956-ffa450edef68
The current implementation expects <default> to be formated like:
directive_name default_value
If the directive name is not there, no default value can be extracted and it is missing in the quickreference table.
This commit adds a basic check to see if the formating looks correct. It catches cases where the directive name is omited or is misspelled.
If it generates too much noise, feel free to revert or improve :)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1852285 13f79535-47bb-0310-9956-ffa450edef68
Use priority to remove the ambiguity.
The only rational for choosing "3" and "4" for these priorities, is that "4" is related to <h4> tags, and 3=4-1 for the previous level.
Tested with the actual Xalan XSL engine:
./build.sh all
with and without the change.
Outputs are exactly the same.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1842165 13f79535-47bb-0310-9956-ffa450edef68
Use priority to remove the ambiguity.
The only rational for choosing "3" and "4" for these priorities, is that "4" is related to <h4> tags, and 3=4-1 for the previous level.
Tested with the actual Xalan XSL engine:
./build.sh all
with and without the change.
Outputs are exactly the same.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1842160 13f79535-47bb-0310-9956-ffa450edef68
So simplify the xsl rules accordingly.
Tested with the actual Xalan XSL engine:
./build.sh all
with and without the change.
Outputs are exactly the same.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1842146 13f79535-47bb-0310-9956-ffa450edef68
All the directives are collected in some JS arrays, so that it is easier to upgrade the list
in prettify.js when new directives are added.
'build.sh' will be updated accordingly. A new build target ('prettify') will be added to
update this list. The resulting file is: docs/manual/list_for_prettify.txt
This new file is heavily inspired from convmap.xsl.
It should be possible to go further, but this is already a first step.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1828598 13f79535-47bb-0310-9956-ffa450edef68
This is convenient and consistent with httpd.a.o
Getting a link to a section or a directive is already possible from the TOC, but having it available directly in-place is, IMHO, much more useful.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1828588 13f79535-47bb-0310-9956-ffa450edef68
This commit is a follow up of r1805189, in which
a new logic was added to allow to repeat a directive
name only if its type is different (like SSLPolicy
and <SSLPolicy>). The change broken french translations
since the $this variable, containing the translated
sections, was not used anymore.
The XPath code could surely be improved, but it seems
more pressing to allow our translators to get back
to their daily work without interference.
build.sh validate-* worked fine, as well as the build.sh fr
translation.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1806443 13f79535-47bb-0310-9956-ffa450edef68
In r1805193 synopsis.xsl was changed to allow two directives
of different type (like <SSLPolicy> and SSLPolicy) to share
the same name but have different ids (and please validate-xml/xhtml).
The downside of this action was that all the quicklinks to
existing directive sections (like <If>, <VirtualHost>, etc..)
were changed, possibly breaking external clients already
referencing them.
This change introduces a new attribute in the directivesynopsis
DTD, namely 'idtype', that will be appended to 'name'
in the id generation by synopsis.xsl. This will rollback
link names to their previous values and will allow documentators
to fine tune directivesynopsis sections as they need
(for example we have recently introduced mod_md's
ManagedDomain/<ManagedDomain>, and modssl's SSLPolicy/<SSLPolicy>).
This approach seems more precise and less invasive to me.
Of course the name of the attribute can be changed later on
to whatever term would fit best, the main concern for me at
the moment is to restore the trunk documentation to its previous
state.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1805372 13f79535-47bb-0310-9956-ffa450edef68
This commits is a follow up of r1805189 and it is meant
to allow directives with the same name but different type
to coexist in the same document without triggering errors
while executing validate-xhtml.
For example: mod_md.xml recently introduced the following:
* ManagedDomain
* <ManagedDomain> (this one is type=section)
In my opinion this is a perfectly valid use case and it should
be allowed/handled correctly by the doc generation process/validation.
In order to avoid clashing the directive ids will get a suffix
called "section" if type=section will be present as param.
Quicklinks, <directive> links have been updated to the new
scheme to avoid dandling pointers in the doc.
Comments/reviews are welcome, if I left something behind
please let me know.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1805193 13f79535-47bb-0310-9956-ffa450edef68
directive HTML if more than one
directive share the same name.
This has happened when mod_md.xml was introduced,
and the following directives shared the same name:
* ManagedDomain
* <ManagedDomain>
With the current code each time that a node needs
to be rendered it will emit a duplicate, ending up
in the above example with 4 sections rather than two.
Uniqueness of sections will be ensured by the HTML
elements ids, to avoid errors before committing for
example (accidental duplicates, etc..).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1805189 13f79535-47bb-0310-9956-ffa450edef68
This page pulls in directives that declare an <override> element and
groups them by class. The documentation for each class comes from
overrides.xml. Any undocumented classes are flagged with a boilerplate
fallback text (this situation is only likely to occur with a misspelling
or otherwise invalid <override> somewhere else in the documentation).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/trunk-override-index@1793922 13f79535-47bb-0310-9956-ffa450edef68
Changes discussed in docs@ and implemented:
- Moved Httpd to HTTPD
- Created a new link to quickly open a bug in Bugzilla
- Modified the link called "Open bugs" to "Known issues" and appended
the bugzilla component name to the URL. In this way the user will only
see bugs related to the module under review, not all the httpd ones.
A little hack was necessary since some mpms have inconsistent naming
(e.g. mpm_event in Bugzilla and event in docs).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1740735 13f79535-47bb-0310-9956-ffa450edef68
This change should help users not familiar with the httpd changelog and bugzilla to check them
before asking in IRC/users@/etc if httpd has a bug or not. The wording and position of the
panel can of course be changed; this is a proposal to improve user experience while consulting
doc pages related to httpd modules. The change has also been discussed in docs@.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1740110 13f79535-47bb-0310-9956-ffa450edef68
