From: Nikolai Grigoriev (grig@renderx.com)
Date: Wed Jun 02 2004 - 10:21:54 PDT
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@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@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
This archive was generated by hypermail 2.1.5 : Wed Jun 02 2004 - 10:35:35 PDT