This wouldn't ever be perfect, but there's a large set of rules that
could be used to determine formatting-only whitespace. The following
set is a distilled version:
From the XML context:
1. Outside mixed-content
2. Outside where xsl:space "preserve" is in scope
3. Outside defined elements such as 'pre' and 'text'
4. If it precedes an attribute name beginning a new line
5. If it precedes an attribute value on a new line
From text context:
4. Where the number of characters found are (within a defined margin)
is consistent with the current nesting-level - a pattern can normally
be established
5. Where irregular leading whitespace is found on consecutive lines in
a node value
The approach would be progressive where, on first load a minimal set
of 'obvious' formatting is removed, then further options provided to
the developer that steadily impose a more rigorous filtering
Phil Fearon
http://qutoric
On Tue, Jun 7, 2011 at 2:22 PM, Dimitre Novatchev
<dnovatchev(_at_)gmail(_dot_)com> wrote:
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>
--~--
--~------------------------------------------------------------------
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>
--~--