XML::Filter::DetectWS - A PerlSAX filter that detects ignorable whitespace
use XML::Filter::DetectWS;
my $detect = new XML::Filter::DetectWS (Handler => $handler, SkipIgnorableWS => 1);
This a PerlSAX filter that detects which character data contains ignorable whitespace and optionally filters it.
Note that this is just a first stab at the implementation and it may change completely in the near future. Please provide feedback whether you like it or not, so I know whether I should change it.
The XML spec defines ignorable whitespace as the character data found in elements that were defined in an <!ELEMENT> declaration with a model of 'EMPTY' or 'Children' (Children is the rule that does not contain '#PCDATA'.)
In addition, XML::Filter::DetectWS allows the user to define other whitespace to be ignorable. The ignorable whitespace is passed to the PerlSAX Handler with the ignorable_whitespace handler, provided that the Handler implements this method. (Otherwise it is passed to the characters handler.) If the SkipIgnorableWS is set, the ignorable whitespace is simply discarded.
XML::Filter::DetectWS also takes xml:space attributes into account. See below for details.
CDATA sections are passed in the standard PerlSAX way (i.e. with surrounding start_cdata and end_cdata events), unless the Handler does not implement these methods. In that case, the CDATA section is simply passed to the characters method.
When determining which whitespace is ignorable, it first looks at the xml:space attribute of the parent element node (and its ancestors.) If the attribute value is "preserve", then it is *NOT* ignorable. (If someone took the trouble of adding xml:space="preserve", then that is the final answer...)
If xml:space="default", then we look at the <!ELEMENT> definition of the parent element. If the model is 'EMPTY' or follows the 'Children' rule (i.e. does not contain '#PCDATA') then we know that the whitespace is ignorable. Otherwise we need input from the user somehow.
The idea is that the API of DetectWS will be extended, so that you can specify/override e.g. which elements should behave as if xml:space="preserve" were set, and/or which elements should behave as if the <!ELEMENT> model was defined a certain way, etc.
Please send feedback!
The current implementation also detects whitespace after an element-start tag, whitespace before an element-end tag. It also detects whitespace before an element-start and after an element-end tag and before or after comments, processing instruction, cdata sections etc., but this needs to be reimplemented. In either case, the detected whitespace is split off into its own PerlSAX characters event and an extra property 'Loc' is added. It can have 4 possible values:
Note that WS_INTER may not be that useful, so this may change.
The XML spec states that: A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, must be declared if it is used. When declared, it must be given as an enumerated type whose only possible values are "default" and "preserve". For example:
<!ATTLIST poem xml:space (default|preserve) 'preserve'>
The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overriden with another instance of the xml:space attribute.
The root element of any document is considered to have signaled no intentions as regards application space handling, unless it provides a value for this attribute or the attribute is declared with a default value.
[... end of excerpt ...]
This code is highly experimental! It has not been tested well and the API may change.
The code that detects of blocks of whitespace at potential indent positions may need some work. See
Send bug reports, hints, tips, suggestions to Enno Derksen at <enno@att.com>.