Re: [xep-support] Suppressing validation errors

From: Nikolai Grigoriev (
Date: Wed Jun 02 2004 - 10:21:54 PDT

  • Next message: "Re: [xep-support] Suppressing validation errors"


    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:


    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:

    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 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.

    Nikolai Grigoriev

    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service

    This archive was generated by hypermail 2.1.5 : Wed Jun 02 2004 - 10:35:35 PDT