<br><font size=2 face="sans-serif">Nikolai,</font>
<br>
<br><font size=2 face="sans-serif">Many thanks for that very helpful reply.</font>
<br>
<br><font size=2 face="sans-serif">I </font><font size=2><tt>presume you
meant DISCARD_IF_NOT_VALID=false</tt></font>
<br>
<br><font size=2 face="sans-serif">We are using XEP 3.5.1, so I have asked
for that to be upgraded.</font>
<br>
<br><font size=2 face="sans-serif">I think for now I will remove the errant
lines by hand and then review the situation when XEP 3.8 is available.</font>
<br>
<br><font size=2 face="sans-serif">Regards, Doug x2571</font>
<br>
<br><font size=2 face="sans-serif">The content of this message is Applied
Materials Confidential. If you are not the intended recipient and
have received this message in error, any use or distribution is prohibited.
Please notify me immediately by reply e-mail and delete this message
from your computer system. Thank you.</font>
<br>
<br>
<br>
<br>
<table border width=100%>
<tr valign=top>
<td>
<br>
<br>
<br><font size=1 face="sans-serif"><b>"Nikolai Grigoriev" <grig@renderx.com></b></font>
<br><font size=1 face="sans-serif">Sent by: owner-xep-support@renderx.com</font>
<br><font size=1 face="sans-serif">02/06/2004 18:21</font>
<br><font size=1 face="sans-serif">Please respond to xep-support</font>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
<xep-support@renderx.com></font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
Re: [xep-support] Suppressing validation
errors</font>
<br><font size=2 face="sans-serif">
</font></table>
<br>
<br>
<br><font size=2><tt>Doug,<br>
<br>
first of all, let me make three general comments:<br>
<br>
1) You can force XEP to continue formatting despite validation <br>
errors, by setting the following option:<br>
<br>
DISCARD_IF_NOT_VALID=true<br>
<br>
2) Validation strategies are subject to continuous refining. <br>
Judging by the format of your error messages, you use some<br>
pre-3.7 version of XEP. There were significant changes<br>
since that time; I suggest retrying with the latest XEP version.<br>
Moreover, validation strictness will become configurable<br>
in the next release of XEP (3.8, due really soon).<br>
<br>
3) The validation is performed simply by applying an XSLT <br>
stylesheet [folint.xsl], publicly available from Xattic site:<br>
<br>
http://xep.xattic.com/xep/resources/validators/validators.html#xslt<br>
<br>
As an ultimate resort, you can edit this stylesheet and supply <br>
a modified version to serve as the input validator for XEP. <br>
However, this means tampering with delicate subjects;<br>
it is on purpose that we don't document it, and I cannot <br>
recommend this method unless you have no other means <br>
to sort the issue. Please contact me off list (at <br>
support@renderx.com) if you decide to go this way. <br>
<br>
------<br>
<br>
Now, let's analyze your error messages.<br>
<br>
> {![error] Attribute 'generator' cannot occur at element 'fo:root'.}
<br>
> dcm: caused by <fo:root atixslfoext:generator="Arbortext Styler">
<br>
<br>
Yes, this should have been ignored. In XEP 3.7.x, it generates <br>
a warning, rather than an error. In XEP 3.8, such attributes will<br>
be ignored by default.<br>
<br>
>{![error] Element 'fo:wrapper' cannot be a child of 'fo:root'.} <br>
<br>
I disagree. You _cannot_ have wrappers inside fo:root <br>
if you claim conformance to XSL 1.0.<br>
<br>
>{![error] Attribute 'id' cannot occur at element 'fo:wrapper'.} <br>
>dcm: caused by <fo:wrapper id="styler-id-the_end"/>
<br>
<br>
This one is a glitch of the validator. It permits @id attributes <br>
on fo:page-sequences and all descendants thereof. Since your<br>
wrapper appears misplaced, it causes this spurious message. <br>
If you move the wrapper inside a fo:flow/fo:static-content<br>
(where it ought to be), the message will go away.<br>
<br>
> {?[warning] Element 'fosi-passthru' belongs to an unknown namespace}
<br>
> dcm: caused by <atixslfoext:fosi-passthru> <br>
<br>
This one is a warning; we ignore the element. In XEP 3.8, this warning<br>
will be off by default.<br>
<br>
<br>
>{![error] Attribute 'master-reference' cannot occur at element 'fo:block'.}
<br>
>{![error] Attribute 'initial-page-number' cannot occur at element 'fo:block'.}
<br>
>{![error] Attribute 'format' cannot occur at element 'fo:block'.} <br>
><br>
> Arbortext say their code sometimes emits non-inheritable properties
<br>
> of FOs where they aren't applicable, but this isn't an error. <br>
> XEP should just ignore them. <br>
<br>
In 99% of all cases, 'master-reference' on fo:block means a problem <br>
in the stylesheet. I cannot agree with Arbortext claiming it's OK to have<br>
it there. Anyhow, XEP duly ignores these attributes in formatting;<br>
it's only in validation that they trigger an error.<br>
<br>
We ignore many non-inheritable properties on elements that should not<br>
bear them, but only in situations when a descendant of the element can<br>
access it via property-value functions ('from-nearest-specified-value()',
<br>
'from-parent()'etc. etc.). Your case is clearly different.<br>
<br>
> I appreciate that validation is useful, and I wouldn't want to turn
<br>
> it off entirely. Is there anything I can do to stop these validation
<br>
> error messages (for example adding a chunk of xsl, or modifying <br>
> the validation in some way) and allow the conversion to pdf to continue?
<br>
<br>
If you hide these messages, they don't cease to be real problems <br>
in the XSL-FO that Arbortext generates. I believe that setting<br>
DISCARD_IF_NOT_VALID to 'false' and tolerating error messages<br>
would be the right attitude in this case.<br>
<br>
Regards,<br>
Nikolai Grigoriev<br>
RenderX<br>
<br>
-------------------<br>
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'<br>
in the body of the message to majordomo@renderx.com from the address<br>
you are subscribed from.<br>
(*) By using the Service, you expressly agree to these Terms of Service
http://www.renderx.com/tos.html<br>
</tt></font>
<br>