Perché gli editor XSLT inseriscono caratteri di tabulazione o spazio in XSLT per formattarlo? [chiuso]

Why then do existing XSLT editors use tabs or spaces for formatting in the first place?

Immagino perché

• Questa funzione era già predefinita in HTML, XML e editor simili su cui si basa l'ambiente di modifica XSLT
• Gli spazi / le schede migliorano la leggibilità del file e aggiungere spazi reali è più semplice rispetto all'aggiunta di spazi virtuali
• Gli utenti possono avere opinioni su quanto spazio bianco mettere dove e queste opinioni sono a volte informate.
• Le interruzioni di riga significano che i messaggi di errore basati sulla linea sono significativi
• Nella maggior parte dei contesti, lo spazio vuoto extra in XSLT non ha alcun effetto sul documento risultante
• Nei contesti in cui ha un effetto sul documento risultante, in alcuni casi la semantica di quel documento non cambierà.

L'unico vero problema per XSLT è lo spazio bianco nel contenuto misto. In questo caso, come puoi notare, puoi utilizzare xsl:text . Sì, aggiunge un sovraccarico, ed è fastidioso a volte.

Ma in molti anni di lavoro con XSLT in pratica (incluso l'utilizzo di molte attività di punteggiatura molto complicate), la mia impressione è che, a conti fatti, non è una cosa negativa. In effetti, in generale, scoraggerei l'inserimento di testo non elaborato in qualsiasi contesto diverso da xsl:text a causa del pericolo di un problema di spazio bianco significativo.

L'inserimento di un semplice testo statico in XSLT è generalmente qualcosa che si vuole fare solo con parsimonia e dopo un'attenta considerazione. La maggior parte della potenza ed espressività di XSLT è nella sua capacità di rimodellare i dati, piuttosto che le sue capacità di elaborazione del testo. Decidere di aggiungere nodi di testo interi è degno di un tag extra per segnalare "questo sta facendo deliberatamente qualcosa di leggermente inusuale".

Per questo motivo e per via della natura del markup e del testo in XML e XSLT, le attività di elaborazione del testo devono essere eseguite con attenzione. Mettere ciascun nodo di testo nel proprio elemento sulla propria linea, alla pari con altri nodi e istruzioni aiuta in quel processo consapevole.

Infine, vale la pena tenere a mente che XSLT non è terso per cominciare. Un extra di overhead non è quindi un grosso problema. Lo storage a questo livello è economico e, anche se usato frequentemente, i costi di trasferimento aggiuntivi saranno trascurabili una volta preso in considerazione lo gzipping.

Ti incoraggerei a ripensare alla soluzione "un margine sinistro dinamico per ogni nuova linea" e ti suggerisco di codificare invece qualcosa che gestisce con garbo il contenuto misto avvolgendo automaticamente gli elementi necessari in xsl:text (che tu potrebbe nascondere). Ciò renderebbe XSLT più resistente ad altri strumenti.

Tutti gli editori che hanno creato gli ultimi 20 anni sono partiti dal punto di vista di vi, Emacs, Visual Studio o uno dei loro equivalenti. Nel 1985, quando Mike Cowlishaw ha scritto uno dei primi editor SGML (LEXX ) per Oxford English Progetto di digitalizzazione del dizionario , ha fatto esattamente ciò che fa il tuo editor XSLT: separa la visualizzazione dalla rappresentazione. È una vergogna che non è mai stata realmente presa.

Perché quelli che scrivono l'editor XSLT, non lo usano da soli per scrivere XSLT, e lo confondono con un semplice XML dove lo spazio bianco conta di meno.