From: Douglas_Morrison@contractor.amat.com
Date: Thu Jun 03 2004 - 07:00:28 PDT
Nikolai,
Many thanks for that very helpful reply.
I presume you meant DISCARD_IF_NOT_VALID=false
We are using XEP 3.5.1, so I have asked for that to be upgraded.
I think for now I will remove the errant lines by hand and then review the
situation when XEP 3.8 is available.
Regards, Doug x2571
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.
"Nikolai Grigoriev" <grig@renderx.com>
Sent by: owner-xep-support@renderx.com
02/06/2004 18:21
Please respond to xep-support
To: <xep-support@renderx.com>
cc:
Subject: Re: [xep-support] Suppressing validation errors
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
-------------------
(*) 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 : Thu Jun 03 2004 - 07:12:27 PDT