XSLT ve olası alternatifler [kapalı]


15

Bir XML dosyasını diğerine (HTML vb.) Dönüştürmek için XSLT'ye bir göz attım. Şimdi XSLT'nin (standart ve kullanılmış bir araç olarak) faydaları olduğunu gördüğümde, birkaç nedenden dolayı isteksizim

  • XSLT işlemciler oldukça büyük / kaynak aç görünüyor
  • XML, programlama için kötü bir gösterimdir ve XSLT'nin konusu budur.

XSLT'yi burada trol etmek istemiyor olsa da, size bir alternatiften ne beklediğime dair bir fikir vermek için sevmediğim şeyleri belirtmek istiyorum.

Bazı Lisp geçmişine sahip olmak, bazı lisp tabanlı ağaç-yapı dönüşümleri için daha iyi yollar olup olmadığını merak ediyorum. DSSSL referansları gördüm, ne yazık ki DSSSL hakkında çoğu bağlantı öldü, bu yüzden onu gösteren bazı kodları görmek zaten zor. DSSSL hala kullanılıyor mu? Dokümanlara bakarken bir kez openjade kurduğumu hatırlıyorum.

Jeff Atwood'un blog yazısı XSLT yerine Ruby kullanıldığında ipucu veriyor gibi görünüyor.

Xml olmayan bir programlama dilinde XSLT'ye benzer XML dönüşümleri yapmanın akılcı yolları var mı? Giriş için açık olurdum

  • XML dönüşümlerini kolaylaştıran komut dilleri için kullanışlı kütüphaneler
  • özellikle (ama sadece değil) lisp benzeri dönüşüm dilleri veya Ruby vb.

Şimdiye kadar bulduğum birkaç şey:


HXT ve Haskell'i sık sık kullanıyorum, çok hoş
Daniel Gratzer

5
Adil olmak gerekirse, Ruby'yi savunan Jeff Atwood değil, Ruby'yi tercih eden Martin Fowler'den alıntı yapıyor. Fowler'ın orijinal yazısı burada: martinfowler.com/bliki/MovingAwayFromXslt.html Ve 10 yıl önce 2003 yılında yazılmıştır - Sanırım XSLT 2.0 2007'de ve birçok iyileştirmeyle ve XPath 2.0 2010'da çıktı.
FrustratedWithFormsDesigner

Yanıtlar:


18

Teknolojileri derin deneyimleriniz olmadığında değerlendirmek zordur, ancak elbette kararlarınızı vermeniz gerektiğinde, bu nedenle bu ikilemin basit bir cevabı yoktur.

İki endişeden bahsediyorsunuz: performans ve kullanılabilirlik. Her ikisini de aşağıda ele almaya çalışacağım.

İlk olarak, performans. Elbette performans sadece dile değil, aynı zamanda uygulamaya ve kullanıcıların uzmanlığına da bağlıdır. Farklı XSLT işlemciler performans açısından büyük ölçüde değişebilir ve aynı işlemci, nasıl kullanıldığına bağlı olarak büyük ölçüde değişebilir (örneğin, Saxon ile, performans sorunları olan kişilerin genellikle zayıf bir kombinasyon olan DOM ile kullandıkları bulunmuştur. ve bunun yerine Saxon'un yerel ağaç modelini kullanırsanız performans on kat artabilir). Yani ilk tavsiye kulaktan kulağa performans göstermemek, ölçmek; ve ikinci tavsiye, ölçümü yapan kişinin aptalca hatalar yapmamak için yeterli deneyime sahip olduğundan emin olmaktır. Söylemesi yapmaktan daha kolay.

Kabaca, dönüşüm işlerini iki kategoriye ayırabilirsiniz: basit ve karmaşık. Basit dönüşümler için, iyi bir XSLT işlemci ile zaman ayrıştırmak ve serileştirmek için harcanır ve XSLT işlem süresi neredeyse resme girmez. Başka herhangi bir teknoloji aynı ayrıştırma ve serileştirme maliyetlerine maruz kalacağından, dönüşüm teknolojisi seçimi büyük bir fark yaratmayacaktır (belki de akışı kullanarak çok düşük seviyeli kodlama için çok hariç, ancak pek çok kişi programlama yapamaz bunu uygulamak için gereken zaman ve beceriler). Büyük belgelerdeki karmaşık dönüşümler için, SQL programlama ile aynı sorunları elde etmeye başlarsınız: iyi performans elde etmek, programcının becerileri ve bilgisi ile optimize edicinin yetenekleri arasında iyi bir etkileşim gerektirir. SQL'de olduğu gibi, bu kadar üst düzey bir dilde işlemcinin çok büyük miktarda iş yapmasıyla sonuçlanan birkaç basit ifade yazmak çok kolaydır. Ancak SQL'de olduğu gibi, ne yaptıklarını bilen programcılar acemilerden çok daha iyi olacak.

İkincisi, kullanılabilirlik. XSLT için XML tabanlı sözdizimi, birçok insanın dil ile ilk karşılaşmasında çok rahatsız edici. Ancak bunu bu şekilde yapmanın iyi nedenleri ve gerçek faydaları vardır: "şablon" argümanı vardır, kodun büyük bir kısmı sonuç belgesine yazılacak XML'den oluşur ve XML yazmanın en iyi yolu XML'dir. Bir de "yansıma" argümanı var; büyük karmaşık sistemlerde, stil sayfaları üreten stil sayfalarını bulmak çok yaygındır. Sonra "araçlar" argümanı var; Bir XML mağazasındaysanız, muhtemelen sözdizimine yönelik düzenleyiciler gibi çok fazla XML aracına sahipsiniz ve programlarınızı ve verilerinizi işlemek için aynı araçları kullanmak iyidir. Dezavantajları karşılaştırıldığında oldukça kozmetiktir: orada ' Düzenlemeye dahil olan tuş vuruşlarının sayısı (iyi bir düzenleme aracıyla kolayca sabitlenir) ve kodun ayrıntı düzeyi vardır (okunabilirliğini azaltır). Düzgün ifadeler, düzenli ifadeler ve stil sayfası işlevleri gibi özelliklerin tanıtılmasıyla XSLT 2.0'da büyük ölçüde azaltılır: XSLT 2.0'dan tam olarak yararlandıklarında birçok stil sayfası yarıya veya üçte bire küçülür.

DSSSL'den bahsettiğinizde beni alaycı bir gülümsemeyle bırakır. DSSSL'yi hiç kullanmadım, ancak duyduğum hikayeler, sözdiziminin gizemli olduğu ve verilerin sözdizimiyle (SGML) ilgisiz olduğu için yetersiz olduğuydı. XSLT için bir XML sözdiziminin kullanılması, DSSSL deneyimiyle güçlü bir şekilde motive edildi.

XSLT'yi seven insanlar var ve ondan nefret eden insanlar var. Şaşırtıcı olmayan bir şekilde, onu çok kullanan kişiler ilk kategoriye girme eğilimindedir. Bundan hoşlanmayanlar genellikle "XSLT yolunu düşünmeyi" öğrenmemiş olanlardır. Bir programlama dilinin düşünme şeklinizi etkilememesi gerektiğini savunabilirsiniz, ancak bunu yapar: kural tabanlı bir dilde yazmak, zorunlu bir dilde yazmaktan farklı bir zihniyet alır. Birçok programcının ilk tepkisi daha az kontrol sahibi olmalarıdır (bilgisayara adım adım ne yapılacağını söylemek yerine sorunu tanımlamak). İnsanların SQL ile ilk kez ne zaman tanıtıldığını görmek için kullandığınız reaksiyona çok benzer. Bu günlerde insanlar SQL'leri kariyerlerinde daha erken öğreniyorlar, böylece daha az zihinsel yeniden ayarlama gerekiyor.

Sonuç olarak, aşk / nefret tepkilerine değil, nesnel ölçülebilir ölçütlere dayanan bir teknoloji seçmelisiniz. Bu ölçümleri yapmak zor. Ancak XSLT'yi çok yoğun ve çok başarılı bir şekilde kullanan birçok insan var, bu yüzden yapılabileceğinden şüphe yok.


2
"Kural tabanlı dil" için en yaygın kullanılan terim, bildirimsel bir dildir.
Daniel Gratzer

@Michael Kay - İyi koy. Şahsen XSLT'yi seviyorum ve C # ile kullanıyorum. Ayrıca XSL-FO ile PDF belgelerini üretmek için kullanıyorum. XSLT güçlü, çok güçlü, büyük miktarda veriyi hızlı bir şekilde HTML, XSL-FO, XML veya Metin'e dönüştürmeme izin veriyor.
PhillyNJ

3

Bağlam hakkında ek bilgi olmadan, cevaplamak zordur.

Yine de neden XSLT kullanmak istemediğinizi anlamıyorum. Bu iş için doğru araç ve güçlü bir araç. Özellikle bir XML'i diğerine dönüştürmek için yapılır.

XSLT işlemciler oldukça büyük / kaynak aç görünüyor

Bunu destekleyecek sabit verileriniz var mı? XSLT bu XSLT ve bulunan kullanarak çözümünü uygulamaya mı olduğu performans ile ilgili tüm işlevsel olmayan gereksinimlerini yerine getirirken imkansız bir ürün sunmak için yapar darboğaz?

İstatistiksel veriler ve profil oluşturma olmadan, verilen bir çözümün işe yaramayacağını makul bir şekilde iddia edemezsiniz. İşlevsel olmayan gereksinimler yeterince makul mü? Örneğin, XSLT'yi başka bir alternatifle değiştirerek birkaç yüz milisaniye kazanmak için on günlük geliştiricilerin çalışmalarını boşa harcamayı tercih eder misiniz? Buna değer mi?

XML, programlama için kötü bir gösterimdir ve XSLT'nin konusu budur.

Yani bir XML'i diğerine dönüştürmek istiyorsunuz, ancak "XML kötü bir gösterim" olduğu için XSLT kullanmak istemiyor musunuz?

XML'i sizi çok rahatsız eden bir tür programlama dili olarak kullanıyor olmanız durumunda, bunu programlama olarak değil, bir takım dönüşüm kuralları olarak görün.

Elle XSLT yazmanıza bile gerek yok. Grafiksel olarak bir XML'yi bir başkasına eşleştirmenize izin veren birçok ETL düzenleyicisi vardır: herhangi bir programlama gerekmez. Bazıları çıkış olarak XSLT kullanır.


XSLT tabanlı sayfalarda kaynak sorunları ile karşılaştım, grafik bir araçla oluşturuldular, ancak daha büyük dosyalarla çalışmayı durdurdular.
wirrbel

1
Sonra muhtemelen senin orada sorunları vardır XSLT filedeğil XSLT Transformationskendileri
Malaki

Şimdi XML'i kınamıyorum, aslında veri gösterimi için uygun olduğunu düşünüyorum (özellikle işaretleme için). Bir "programlama dili" olarak - ve XSLT, alana özel bir programlama dilidir - bu rahatsızlık vericidir. <xsl: whatever> Sorgu özniteliklerindeki etiketler, meta diller (xpath, $ gösterim vb.), XML ile eşlenmeyen her şey öznitelik tırnaklarına konur. XML'in s-ifade temsilinin bir izlenimi için: blog.getprismatic.com/blog/2013/1/22/… bu kadar uzak bir yerde XML ve ve proglang işe yaramaz gibi görünebilir
wirrbel

1

Ham XSLT ve XSLT motoruna geçirdiğiniz bazı parametreleri temel alarak XML oluşturmak için XSLT kullanıyorsanız, geçici bir XML yaklaşımı kullanmak, anlamak ve korumak çok daha kolaydır.

Bıyığın XSLT'nin yerine kullanıldığı bir projede bulundum ve sonuç, herkesin düzenleyebileceği ve ayarlayabileceği çok daha basit temel XML dosyaları oldu, bu proje çalışması tamamen sessizce oturacak bir veya iki cesur ruha aktarıldı. dökülen ter boncukları ile ...

Şablon yaklaşımı, temel XML de kendi başına geçerli veriler olduğunda ve XSLT'nin alternatif bir gösterim veya kaynak XML'den bir özüt sağlamak için kullanıldığında kullanım için uygun değildir.


ne yaptığını ve neden sorulan soruya cevap vermesini öneriyorsunuz? "Yalnızca bağlantı yanıtları" Stack Exchange'de pek hoş karşılanmıyor
gnat

1
Cevabınızı geri bildiriminizle birlikte inceledik
Michael Shaw

0

XML bir Programlama Dili değildir

XML, Verileri Aktarma / Aktarma yöntemidir.
XSLT komutunun yaptığı, Verileri belirli bir şekilde sorgulamak ve başka bir Veri Aktarım Nesnesi / Belgesine koymak için Xpath kullanmaktır.

VE / VEYA

XSLT, XML'inizi XML belgesine dönüştürebilmenin başka bir yolu olan HTML'ye dönüştürebilir.

XML'i değiştirmek veya XML Belgesi Oluşturmak istiyorsanız, istediğiniz sayıda dili kullanabilirsiniz: C #, VB, Ruby, Etc.

genellikle bir XML Belgesini dönüştürmek için bir XSLT dosyası kullandığınızda, hala orijinal XML Belgeniz vardır, orijinal Belgeyi gerçekten değiştirmezsiniz, gerçekten yeni bir belge oluşturursunuz.


1
Wikipedia diyor ki: "XSLT, Turing-tam bir dildir, yani bir bilgisayar tarafından yapılabilecek herhangi bir hesaplamayı belirtebilir." XML'in kendi başına bir programlama dili olduğunu söylemedim.
wirrbel

Kullandığım programlama dillerinde "XML programlama için kötü bir gösterimdir" dediniz XML Dosyalarından Veriyi Kolayca Çekebilirsiniz. XSLT, birçok Hesaplama yapabilme ve bu Verileri başka bir Veri Aktarımı nesnesine / Belgesine tükürme konusunda zemin kazanıyor. SQL Server SQL Server gibi bir çok şey yapabilirsiniz ama çoğunlukla arka uç, ön uç değil. XSLT gibi SQL, Verileri belirli bir şekilde sorgular, ancak bu sorgunun sonuçlarını asla rapor olarak vermek istemezsiniz, bilgileri bir rapor oluşturucuya göndermek istersiniz
Malachi

2
XSLT verileri sorgulamaz, XPATH sorgulamayı yapar. XSLT, ayrıştırılmış xml ile ilgili talimatları tanımlayan bildirici bir dil değil mi?
PhillyNJ

XSLT, dönüşüm kurallarını Xpath'i kullanabileceği kalıplara göre tanımlar. Yani xsl:for-each xsl:apply-templates, xsl:if xsl:call-template xsl:value-ofdönüşüm kurallarını tanımlamak gibi üst düzey programlama yapılarına sahip olabilirsiniz .
wirrbel

1
@PhilVallone katılıyorum. Orada yanılmışım. wirrbel, XSLT / XSL'nin ne olduğu hakkında sizinle tartışmayacağım, XML belgenizi başka bir XML Belgesine dönüştürmek istiyorsanız, XSLT / XSL'yi kullanmak isteyeceksiniz.
Malachi

0

XSLT'nin iyi olmadığı parçalar için XSLT kitaplıklarını Java veya C ++ ile birleştiren birden fazla XML işleme sisteminde çalıştım. 20 MB XML dosyalarında bile çok iyi XSLT performansı elde eden kütüphaneler vardır, ancak XSLT'nin bağlam, değişkenler ve gerçekten karmaşık dize desenleri ile bazı sınırlamaları vardır. Üzerinde çalıştığım her sistemde Java / C ++ 'da birkaç şey yapıldı çünkü bağlam önemliydi ya da karmaşık regex ifadeleri yardımcı oldu. Benim paketim, XSLT artı seçtiğiniz dildeki bazı ek kodların XML'i dönüştürmek için iyi bir yol olmasıdır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.