[xep-support] Suppressing validation errors

Nikolai Grigoriev grig at renderx.com
Wed Jun 2 10:21:54 PDT 2004


Doug,

first of all, let me make three general comments:

1) You can force XEP to continue formatting despite validation 
errors, by setting the following option:

DISCARD_IF_NOT_VALID=true

2) Validation strategies are subject to continuous refining. 
Judging by the format of your error messages, you use some
pre-3.7 version of XEP. There were significant changes
since that time; I suggest retrying with the latest XEP version.
Moreover, validation strictness will become configurable
in the next release of XEP (3.8, due really soon).

3) The validation is performed simply by applying an XSLT 
stylesheet [folint.xsl], publicly available from Xattic site:

http://xep.xattic.com/xep/resources/validators/validators.html#xslt

As an ultimate resort, you can edit this stylesheet and supply 
a modified version to serve as the input validator for XEP. 
However, this means tampering with delicate subjects;
it is on purpose that we don't document it, and I cannot 
recommend this method unless you have no other means 
to sort the issue. Please contact me off list (at 
support at renderx.com) if you decide to go this way. 

------

Now, let's analyze your error messages.

> {![error] Attribute 'generator' cannot occur at element 'fo:root'.} 
> dcm: caused by <fo:root atixslfoext:generator="Arbortext Styler"> 

Yes, this should have been ignored. In XEP 3.7.x, it generates 
a warning, rather than an error. In XEP 3.8, such attributes will
be ignored by default.

>{![error] Element 'fo:wrapper' cannot be a child of 'fo:root'.} 

I disagree. You _cannot_ have wrappers inside fo:root 
if you claim conformance to XSL 1.0.

>{![error] Attribute 'id' cannot occur at element 'fo:wrapper'.} 
>dcm: caused by <fo:wrapper id="styler-id-the_end"/> 

This one is a glitch of the validator. It permits @id attributes 
on fo:page-sequences and all descendants thereof. Since your
wrapper appears misplaced, it causes this spurious message. 
If you move the wrapper inside a fo:flow/fo:static-content
(where it ought to be), the message will go away.

> {?[warning] Element 'fosi-passthru' belongs to an unknown namespace} 
> dcm: caused by <atixslfoext:fosi-passthru> 

This one is a warning; we ignore the element. In XEP 3.8, this warning
will be off by default.


>{![error] Attribute 'master-reference' cannot occur at element 'fo:block'.} 
>{![error] Attribute 'initial-page-number' cannot occur at element 'fo:block'.} 
>{![error] Attribute 'format' cannot occur at element 'fo:block'.} 
>
> Arbortext say their code sometimes emits non-inheritable properties 
> of FOs where they aren't applicable, but this isn't an error. 
> XEP should just ignore them. 

In 99% of all cases, 'master-reference' on fo:block means a problem 
in the stylesheet. I cannot agree with Arbortext claiming it's OK to have
it there. Anyhow, XEP duly ignores these attributes in formatting;
it's only in validation that they trigger an error.

We ignore many non-inheritable properties on elements that should not
bear them, but only in situations when a descendant of the element can
access it via property-value functions ('from-nearest-specified-value()', 
'from-parent()'etc. etc.). Your case is clearly different.

> I appreciate that validation is useful, and I wouldn't want to turn 
> it off entirely. Is there anything I can do to stop these validation 
> error messages (for example adding a chunk of xsl, or modifying 
> the validation in some way) and allow the conversion to pdf to continue? 

If you hide these messages, they don't cease to be real problems 
in the XSL-FO that Arbortext generates. I believe that setting
DISCARD_IF_NOT_VALID to 'false' and tolerating error messages
would be the right attitude in this case.

Regards,
Nikolai Grigoriev
RenderX

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html



More information about the Xep-support mailing list