Mailing List Archive

manual/developer/modguide.xml is not a valid XML document
Hi all,

Have you tried to enter "./build.sh validate-xml" for trunk or 2.4 branch ?

I get hundreds of lines containing
"manual/developer/modguide.xml:1647:125: Attribute "style" must be
declared for element type ....." which hide other errors which may appear


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: manual/developer/modguide.xml is not a valid XML document [ In reply to ]
On 22-04-2012 14:24, Lucien GENTIS wrote:
> Hi all,
>
> Have you tried to enter "./build.sh validate-xml" for trunk or 2.4 branch ?
>
> I get hundreds of lines containing
> "manual/developer/modguide.xml:1647:125: Attribute "style" must be
> declared for element type ....." which hide other errors which may appear
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>
Don't forget the equally famous one:
The content of element type "p" must match
"(em|strong|code|a|br|directive|module
|program|img|cite|q|dfn|var|transnote|glossary|phonetic)"


I've seen the errors, and I know of _a_ solution, which is to loosen up
common.dtd in the build system to allow styles within a <code> tag (and
subsequently allow for <pre> inside a <p>), but the real rub here is
what Igor wrote in an email earlier this week; We don't have a
highlighting function for our documents, yet alone a way to distinguish
between configuration examples and source code, so we're forced to use
"invalid" XML segments in order to make the end result properly readable
for our readers.

So again, I implore anyone who has knowledge of, or knows someone who
knows someone who can help us in creating some form of highlighting
feature, please step forward and let us know. The alternate route would
be to just revert every example back to plain text, which would render
most of it quite unappetizing to most readers.

With regards,
Daniel.

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: manual/developer/modguide.xml is not a valid XML document [ In reply to ]
* Daniel Gruno wrote:

> I've seen the errors, and I know of _a_ solution, which is to loosen up
> common.dtd in the build system to allow styles within a <code> tag (and
> subsequently allow for <pre> inside a <p>),

<pre> is not allowed inside <p>, because both are blocks (in HTML then) and
nesting is forbidden there.

Also, style attributes are BAD. If you want to extend common.dtd, use
classes and extend the css files (or, better: add a new one).

> but the real rub here is
> what Igor wrote in an email earlier this week; We don't have a
> highlighting function for our documents, yet alone a way to distinguish
> between configuration examples and source code, so we're forced to use
> "invalid" XML segments in order to make the end result properly readable
> for our readers.

Fix the DTD and the XSLT. Breaking the build system is not a solution.

> So again, I implore anyone who has knowledge of, or knows someone who
> knows someone who can help us in creating some form of highlighting
> feature, please step forward and let us know. The alternate route would
> be to just revert every example back to plain text, which would render
> most of it quite unappetizing to most readers.

I suggest pygments. If we get that to run with jython, we could use it to
auto-highlight code. But until then, it's plain text, yes; so please
revert.

nd
--
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: <http://pub.perlig.de/books.html#apache2>

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: manual/developer/modguide.xml is not a valid XML document [ In reply to ]
On 23-04-2012 01:42, André Malo wrote:
> * Daniel Gruno wrote:
>
>> I've seen the errors, and I know of _a_ solution, which is to loosen up
>> common.dtd in the build system to allow styles within a <code> tag (and
>> subsequently allow for <pre> inside a <p>),
>
> <pre> is not allowed inside <p>, because both are blocks (in HTML then) and
> nesting is forbidden there.
>
> Also, style attributes are BAD. If you want to extend common.dtd, use
> classes and extend the css files (or, better: add a new one).
>
>> but the real rub here is
>> what Igor wrote in an email earlier this week; We don't have a
>> highlighting function for our documents, yet alone a way to distinguish
>> between configuration examples and source code, so we're forced to use
>> "invalid" XML segments in order to make the end result properly readable
>> for our readers.
>
> Fix the DTD and the XSLT. Breaking the build system is not a solution.
>
>> So again, I implore anyone who has knowledge of, or knows someone who
>> knows someone who can help us in creating some form of highlighting
>> feature, please step forward and let us know. The alternate route would
>> be to just revert every example back to plain text, which would render
>> most of it quite unappetizing to most readers.
>
> I suggest pygments. If we get that to run with jython, we could use it to
> auto-highlight code. But until then, it's plain text, yes; so please
> revert.
>
> nd
I have fixed the nesting issues that were, and changed all style
elements to classes instead, pending whichever solution might be deemed
the best. It will still require a laxer version of common.dtd which
allows for class tags within <code> elements, just as it is currently
allowed for <p> elements, but I'll need some input on whether people
think it's okay to change common.dtd to accommodate this, or whether
everything should just be plain-text, which would undoubtedly be a pain
to read.

With regards,
Daniel.

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