Re: Trimming (formatting-only) leading tabs/spaces fro

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@xxxxxxxxxxx>
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