--- Comment #3 from Vincent Hennebert <vhenneb...@gmail.com> 2009-11-03
09:33:18 UTC ---
(In reply to comment #2)
> > Question remains: is there any risk that other elements containing text may
> > be
> > affected by that xml:space?
> To answer that I want to mention why I added the xml:space=preserve in the
> first place: Editing IF in an XML editor frequently messed up the formatting
> because of pretty-printing.
A comment in the source code explaining that would have been welcome.
> FOP itself doesn't really profit from it (and can
> do without). The default behaviour is application-specific which is fine in
> FOP, but an XML editor doesn't know about that except if there's an XML Schema
> active in the XML editor which could supply the intended default behaviour.
> I haven't tested whether that would really work.
So IIUC the xml:space attribute won't even be honoured by the XML editor if the
schema is not associated with the document when it's loaded? Unless some code
has been written in the editor to recognize the standard attributes in the xml
namespace, even if not backed by a schema.
> > Also, is there any testing framework for the intermediate format, to test
> > that > change?
> The only thing we do now is test using XPath statements and I don't think I've
> written any test that looks for the xml:space attribute. Essentially, you can
> simply remove the xml:space and the tests will run through as before. As said
> above, the only case where xml:space is useful is when it comes to manually
> editing the IF in an XML editor. It avoids breaking the content.
If nobody objects I'm going to move the definition of the xml:space attribute
to the <document> element. If its purpose only is to avoid overzealous
pretty-printing by XML editors, FOP wouldn't be affected and those editors
should still behave properly.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.