How do you know that the spaces are "formatting-only"?
I have heard about cases (mostly with HTML) where this cannot be safely assumed.
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.
On Tue, Jun 7, 2011 at 5:47 AM, Philip Fearon
<philipfearon(_at_)qutoric(_dot_)com> wrote:
Say, (hypothetically) there was an XSLT-based system that included an
editor that (if used) needed to trim leading tabs/spaces from XSLT
when first loading a file, so as to provide a continously formatted
view of the XSLT code as it was edited.
Provided that this was done relatively reliably (i.e. without trimming
significant tab and space characters) and predictably, would this
cause significant problems in an XSLT development, test or production
environment?
So, would other editors, viewers, diff-tools, version-control systems,
auto-documentation systems etc. be adversely affected? If such
formatting characters needed to be added again, would it be best just
to add them when required (letting the consumer choose the formatting
style)?
I ask, because the popular consensus seems to be that trimming
non-XSLT code of formatting characters in this way would be a major
issue. This is because of established working methods and tools that
don't/won't/can't tolerate changes to whitespace (this seems to be
quite an emotive issue).Now, whitespace has added significance (an
understatement I think) in XML/XSLT systems. My experience (such that
it is) in XSLT is that working methods and tools have therefore
evolved to manage whitespace (removing it, comparing it, adding it, or
ignoring it) more effectively than text-only tools, trimming XSLT of
tabs/spaces therefore shouldn't be a problem and may even provide more
flexibility, does this hold up in the wider XSLT world?
Phil Fearon
http://qutoric.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--