Andreas L Delmelle wrote:
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 ' '
I think they call that "insignificant white space", and that would not
be counted as PCDATA. Partly explained here, but not definitive either way:
http://www.w3.org/TR/REC-xml/#sec-white-space
Also, this old email[1], which included the above link, has an
interesting quote of how to interpret whitepace:
Whitespace verifies as #PCDATA if #PCDATA is allowed at a particular
point. If #PCDATA is NOT allowed at a particular point, the whitespace
is ignored for the purposes of verifying.
[1] http://lists.xml.org/archives/xml-dev/199806/msg00386.html
But I'm far from an expert on this stuff.
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 :-/]
I don't think that whitespace-only nodes are being created by FOP
anyway, if the whitespace just exists between two consecutive opening
tags. So this problem may not be occuring for the user as it is.
<soapbox>But it is a common misperception[2] that strict validation is
mean and cold-hearted, when in fact is it saves people from submitting
erroneously built documents/invoices. "Just a warning" means that the
user is required to scroll through the log output of every document
generation, just to make sure that the document FOP produced is valid,
and if they fail to do that, then they may submit an incorrect document
or invoice. For every hacker irritated by strict validation, two or
three are probably saved by it--especially billing invoices, where you
almost certainly would want to halt if you had an XSLT error which would
otherwise cause an invalid invoice to be created.</soapbox>
Thankfully FOP has both a strict and non-strict version to suit either
preference. Human nature being what it is though, most who clamor for
the latter, as soon as it is provided to them, start using the former
anyway.
Glen
[2] http://marc.theaimsgroup.com/?l=fop-dev&m=111365780207108&w=2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
