On Mar 7, 2006, at 02:38, Glen Mazza wrote:
Hi Glen,
Andreas L Delmelle wrote:
On Mar 6, 2006, at 10:05, Florent Georges wrote:
The fo:instream-foreign-object flow object has a child
from a non-XSL namespace. The permitted structure of
this child is that defined for that namespace.
So it is required to an IFO to have a child element, isn't
it?
Yes. Exactly one child that is not in the XSL-FO namespace.
And to don't have non-whitespace #PCDATA. Right?
Hmm... Yes, if I catch your intention correctly.
So an FO validator would have to report an error for both the
above IFOs, isn't it?
I'd think so, yes. OTOH, if you have an i-f-o that contains some
text, and then a foreign XML node, I'd assume that a warning
would suffice...
I disagree, although not enough to resubscribe to FOP-DEV and veto
such a matter. PCDATA isn't allowed for fo:i-f-o. Those FO's
which may have PCDATA are expressly defined in the XSL specification.
I see your point... maybe we can do something with the
strictValidation switch here. My concern here is that the first two
cases are obviously wrong (since the required non-XSL child node is
absent).
In the latter case, however:
<fo:instream-foreign-object>
<svg:svg ...>
...
</svg:svg>
</fo:instream-foreign-object>
Note that the i-f-o now contains two text nodes (= #PCDATA):
'
  ' and ' '
This means we have a choice to either test every one of those
characters, or let the 'error' slip through, possibly with a warning.
Depending on the context, I can imagine users not being very happy if
FOP were to be unconditionally strict here... [suppose i-f-o is on
one of the last pages of a 250 page document :-/]
Any other opinions on this?
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
