Minificateur XML

Le XML apparaît dans pas mal de contextes où chaque octet de taille de transfert compte plus que la lisibilité humaine — un corps de requête SOAP envoyé de façon répétée entre services, une valeur de configuration stockée dans une variable d'environnement à longueur limitée, un flux fréquemment récupéré par des clients automatisés. Effondrer les espaces blancs entre éléments tout en préservant soigneusement les sections CDATA, commentaires et valeurs d'attribut exactement telles qu'écrites élimine le surcoût de formatage sans toucher aucune des données que ces sections spéciales protègent délibérément, la même garantie de sécurité que l'analyseur applique en formatant dans le sens inverse.

Comme pour les garanties d'analyse du formateur, la minification ici ne supprime que les espaces blancs entre balises d'éléments — elle ne réordonne pas les éléments, ne réécrit pas les valeurs d'attribut, ni n'altère quoi que ce soit qu'un programme analysant le XML résultant lirait réellement. Un document minifié ainsi et un formaté pour la lisibilité représentent exactement les mêmes données pour tout ce qui les consomme programmatiquement ; seuls leur taille en octets et leur lisibilité humaine diffèrent.

L'espace blanc entre deux éléments frères — l'indentation utilisée purement pour le bénéfice d'un lecteur humain — est ce qui est supprimé. L'espace blanc situé directement à l'intérieur d'un élément avec du texte comme contenu réel, comme un espace délibéré dans une phrase stockée comme texte d'élément, est préservé plutôt que supprimé, le XML n'ayant aucune règle générale selon laquelle l'espace blanc dans le contenu d'un élément serait insignifiant comme le traite souvent le HTML. Bien faire cette distinction fait partie de pourquoi un analyseur construit spécifiquement pour cela le gère correctement là où une approche générale de « supprimer tous les espaces blancs » corromprait du vrai contenu textuel.