ugrás a tartalomhoz

Weboldal XML-ben

janoszen · 2016. Szep. 20. (K), 16.42
Egy másik fórum témában felmerült, hogy a HTML + meta markup helyett XML-t és XSL-t kellene használni arra, hogy a weboldalainkat kiszolgáljuk. Erre példa Hídvégi Gábor kolléga saját oldala.


Az alapján, ami abból a threadből kiderült, ennek a megközelítésnek a következő előnyei vannak:

1. Minden adatot csak egyszer tárolunk el, nem duplikáljuk.

2. Nem alkalmazunk szerver oldali feldolgozást ahhoz, hogy a megfelelő kimeneti formátumra konvertáljuk az adatokat (HTML, RSS, stb). Ezzel CPU-t spórolunk meg.

3. Egységes, követhető adatformátumot kapunk, nincs szükségünk külön metaadatokra.

4. Mindig nyers adatokat küldünk, a klienstől dönti el, hogy mihez kezd vele.


Problémák, amiket én látok ezzel a megoldással:

1. Egyedi XML formátum oldalanként. Teljességgel kizárt, hogy mindenki hajlandó legyen ugyanazt az XML formátumot használni a hasonló adatai tárolására. Vagyis a közvetlen adat-integráció kizárt.

Ahhoz, hogy ez működjön, az XML formátumnak valamiféle közös jellemzőkkel kellene rendelkeznie, ami viszont azt is jelenti, hogy szükség lenne valamilyen schema.org-hoz hasonló markupra.

Ezzel viszont felmerül a probléma, hogy a piaci szereplők már most sem tudnak megegyezni róla, mert a Facebook az OpenGraph-ot nyomja, a Twitter a Twitter-flavor OpenGraph-ot, a Google pedig a schema.org-ot. Lásd még: XKCD.

Végeredményben tök mindegy, hogy HTML vagy XML, az adatainkat továbbra is markupolni fogjuk a mindenféle szolgáltató által támogatott sémák szerint, vagy az XML-ben közvetlenül, vagy az XSL átalakítás során.


2. Kliens oldali támogatás. Noha a böngészők XSL támogatása ma már egész tűrhető, sok adatfeldolgozó kliens nem rendelkezik ilyen képességekkel, és különböző okokból kifolyólag nem is fog. (pl. RSS feldolgozásnál a szükséges CPU kapacitás, de akár a programozói lustaság is.) Az XSL feldolgozás sok feladatra megsokszorozná a szükséges erőforrásokat, holott sok adatátviteli formátumot pont azért találtak ki, hogy ezeket megkönnyítse. Ez sok piaci szereplőnek (RSS aggregátorok) azt jelenti, hogy a költségek a többszörösére nőnek.


3. Lapozás. Ha sok adat van, akkor kénytelen az ember lapozást vinni a rendszerbe. Ezzel viszont felmerül egy probléma, hiszen sokszor több szempont szerint szeretnénk rendezni a weboldalunk elemeit (pl. blogpost), és ezzel kénytelenek vagyunk valamiféle AJAX vagy más egyéb megoldással behúzni az egyes alkotóelemeket. Amellett, hogy ez SEO szempontból öngyilkosság, további probléma, hogy például egy blognál az eredeti threadben írtak szerint a teljes blogpostot letöltené még egy listanézethez is.

Ugyanez igaz a keresésre is, tekintettel arra, hogy keresni nagy adatmennyiségben csak szerver oldalon tudunk, ami viszont szükségessé teszi a dinamikusan generált XML adathalmazt.


4. Statikus tartalmak. Ha minden tartalmat csak egyszer akarunk a szerveren letárolni és mindent adat alapon átvinni, elvesszük a lehetőségét annak, hogy a képeinkből különböző méreteket tartsunk, vagyis a szerveren a legnagyobb szükséges képet kell letárolnunk. Ez azt is jelenti, hogy ez az adatforgalomban is számottevő növekedést fog jelenteni, hiszen a kliens oldalon méretezünk.


5. Üzleti igények. Repülőtársaságok, szállodák, stb. külön szerződéseket kötnek a különböző aggregátor oldalakkal, sokszor nem kevés pénzért. Lehet nem szeretni ezt az üzleti modellt, de tény, hogy az ebből nyereségre szert tevő piaci szereplők nem fogják szivesen látni, ha könnyebb lesz az adatok kinyerése.


6. Adat overhead. Nem minden nézetben van szükségünk minden adatra. Egy webes listanézetben nincs szükség a teljes adatszerkezetre, egy adatfeedben viszont igen. Ez megint csak szükségessé teszi a szerver oldali feldolgozást.


Összességében én úgy látom, hogy az XML / XSL megoldás több, részben architekturális, problémát hordoz. Noha a 2000-es években az volt a jövőkép, hogy ilyen lesz a web, mára már (szerintem) világossá vált, hogy ez, részben emberi, részben műszaki tényezők miatt, nem lesz így.

Egy biztos: ez a megoldás jópár problémát felvet. Cserébe számomra kérdéses, hogy pontosan mi az a probléma amit megold, hiszen adattranszformációkra szerver oldalon így is szükség van.

Ti mit gondoltok?
 
1

Szerintem itt az egyik kulcs

inf3rno · 2016. Szep. 20. (K), 18.12
Szerintem itt az egyik kulcs kérdés, hogy a google, twitter, facebook, stb... botjai mit dolgoznak fel?
- Ha az XML-t, akkor kénytelen Gábor szerver oldalon transzformálni, vagy muszáj lesz REST API-t írnia, ami megszórja linkekkel és metaadatokkal az XML-jét. Ebből a szempontból kevesebb munka lenne a szerver oldali transzformáció, már ha megoldható, hogy tesztelje az oldal a botokat XSL támogatásra.
- Ha a transzformáció kimenetét, szóval az XHTML-t dolgozzák fel ezek a botok, akkor tetszőleges XML-t használhat, és elég a linkeket és a metaadatot elhelyezni az XHTML sablonban (az XSL fájlban).

Szvsz. nem jó az a megkötés, hogy mindent nyers adatként adjunk át a kliensnek, és minden feldolgozást kliens oldalon végezzünk. Adat szűrést, viewmodel készítést, ilyesmiket mindenképp szerver oldalon érdemes végezni, mert ott vannak meg hozzá a megfelelő eszközök. Nyilván nem küldünk át teljes adatbázist a kliensnek, ahogy max felbontásos képeket sem, de ezt szerintem Gábor sem így gondolta. Gondolom ő azt látja ennél a megoldásnál előnynek, hogy az XSL kód izomorf, tehát ugyanúgy működik a kliensen és a szerveren is. Ez most nagy divat js-nél is.

Ha az üzleti igények indokolják, akkor át lehet állni csak szerver oldali transzformálásra, viszont ezzel elveszik az XSL fent említett előnye, szóval simán kiváltható lesz bármilyen másik könnyebben kezelhető sablonnyelvvel, esetleg szerver oldali nyelvvel.

Azt hiszem nagyjából mindent megválaszoltam. Szerintem két esetben lehet életképes ez a fajta megoldás. Ha sikerül valahogy átverekedni a botokon, hogy adjanak infot arról, hogy támogatják e az XSL-t vagy sem, és eszerint kiszolgálni őket. Vagy ha a botok értik az XSL transzformációt, és a kimenetét dolgozzák fel a bemenete helyett. Nem jártam nagyon utána, de pár google keresés után nekem úgy tűnt, hogy nem nagyon értik (vagy értették?) a botok az XSL-t.
2

Botok

janoszen · 2016. Szep. 20. (K), 18.52
A botok kozul nehanynak van XML tamogatasa, es az eredmenykent kapott HTML-t dolgozzak fel, igy pl a Facebook is. Mas botok, jellemzoen pl. az RSS parzerek, viszont erre nem kepesek. Hogy mit kuldenek szerver oldalra, az teljesen valtozo, erre en nem alapoznek semmit. A Facebook pl. */*-t kuld tudtommal, noha tamogat XSLT-t.

Ami szamomra nem vilagos, hogy ez a fajta megkozelites mit old meg? Mert a szerver oldali adattranszformaciot nem uszod meg, a DB-bol ki kell olvasni es be kell tenni XML-be. Ha ezek utan szeretnel meg egy tovabbi transzformaciot XSLT-vel, senki nem akadalyoz meg. De mi elonye van ezt kliens oldalon csinalni, ahol a kiscsillio bongeszo hulyesegeivel kell foglalkozni?

Foleg ha nemzetkozi szinten nezzuk, azert rengeteg outdated Android rohangal a vilagban. CSS-re van matrix, hogy mi mit tamogat, de XSLT-re ugyanilyet nem talaltam.
5

Mindenkinek szükséglete szerint

Hidvégi Gábor · 2016. Szep. 20. (K), 19.03
Az, hogy böngészőkben lehet XML-t transzformálni, egy jó dolog, de az egésznek csak egy okozata, hozománya. Egyébként az XSLT 1.0-t szinte minden böngésző támogatja, amelyik nem, oda meg küldünk HTML-t.

A weboldalak HTML kódjának 99%-a mellébeszélés, értéktelen szemét, ráadásul nehézkes kinyerni belőle a valós információt. Ha adatokkal kezdünk el dolgozni, akkor az olyan paradigmaváltást hozna, mint amikor a számítástechnikában adatbáziskezelőkkel kezdtek el dolgozni: az adatok szűrhetőek, hatékonyan kereshetőek, összehasonlíthatóak lettek.
8

Ha adatokkal kezdünk el

inf3rno · 2016. Szep. 20. (K), 20.26
Ha adatokkal kezdünk el dolgozni, akkor az olyan paradigmaváltást hozna, mint amikor a számítástechnikában adatbáziskezelőkkel kezdtek el dolgozni: az adatok szűrhetőek, hatékonyan kereshetőek, összehasonlíthatóak lettek.


Szóval szerinted az az előnye ennek a megoldásnak, hogyha a kliens úgy gondolja, akkor feldolgozhatja közvetlenül az XML-t transzformáció nélkül?
12

Igen

Hidvégi Gábor · 2016. Szep. 20. (K), 20.38
Persze. És itt kliensen ne csak böngészőt érts, hanem akár egy mobil eszközt vagy egy szemantikus keresőt.
Az XSL ebben az esetben a böngészők számára egy mankó.
3

Tisztázás

Hidvégi Gábor · 2016. Szep. 20. (K), 18.57
Sajnos több minden nem volt egyértelmű az alapján, amit leírtam, továbbá a téma nagy, ezért tisztázom a félreértéseket. Az általam kidolgozott technológia a következőképp működik.

Első blokk

1. Ezt nem teljesen értem

2. Alkalmazunk szerveroldali transzformációt, amennyiben az szükséges. Egy általános keresőt HTML-lel kell ellátni, ezért neki HTML-t kell kiszolgálni, egy feed reader-nek pedig RSS-t.

3. Alapvetően a nyers adatokkal dolgozunk, amikben ott van minden meta információ.

4. A kliensnek olyan adatokat küldünk, amit kér, lásd 2-es pont.

Problémák

1. Egyre nagyobb az igény az egységes adatformátumra, lásd schema.org, de jobb példa erre az Árukereső.hu és minden hasonló oldal.

2. Ahol a kliens nem rendelkezik XML stíluslapok feldolgozásának képességével (XSL), ott szerveroldalon transzformálunk (pl. keresők), vagy nyers XML-t küldünk (mobil alkalmazás saját GUI-val).

3. Bővebb kifejtés nélkül: minden gond nélkül implementálható a lapozás. Épp dolgozom egy infinite scroll megoldáson XSL-re alapozva.

4. A böngészőkben lévő XSL motoroknak lehet paramétereket átadni, azaz a kliensen olyan HTML-t generálhatunk, amiben a megfelelő méretű képek vannak. Tehát például ha valaki mobilt használ, és elforgatja állóra, akkor akár új HTML-t készíthetünk egy ezredmásodperc alatt, amiben más statikus elemeket jelenítünk meg.

5. Az adatok kinyerését csak megnehezíteni lehet, de megakadályozni nem, innentől kezdve lehet harcolni ellene, nem fog sikerülni. Jómagam hobbiszinten jóideje adatok weboldalakból és szolgáltatásokból való kinyerésével foglalkozom, hogy megkönnyítsem a magam életét, még nem volt olyan oldal, ahonnan ne tudtam volna kibányászni azt, amire szükségem volt, értve ide a facebookot például vagy akár bankokat.

6. Ez üzleti logika kérdése.
9

Egységes

janoszen · 2016. Szep. 20. (K), 20.28
De látod, hogy nem lesz egységes. Még a két nagy sem tud megegyezni arról, hogy egységes legyen. Vagy Te hajlandó lennél teszem azt az Árúkereső által előírt XML formátumot használni, csak azért mert Te is termékeket írsz le? És ha jön a Geizhals.at Magyarországra és másik formátumot használ? Akkor megint jól transzformálhatsz és jól nem egységes.

Irreális azt gondolni, hogy a világon mindenki hajlandó ugyanazt az adatformátumot használni még csak termékekre is. Még egy olyan szűk területen, mint pl. az RSS, is van vagy 2-3 versengő formátum.

Vagyis a végén jön az XML a Te általad leírt formátumban, és jól transzformálnod kell minden kliensre. Vagyis nincs olyan valós probléma amit megold.
17

Majd valahogy megoldjuk

Hidvégi Gábor · 2016. Szep. 20. (K), 20.53
János, ez a tipikus magyar hozzáállás, hogy valamit hogyan nem lehet megoldani. Ez engem nem érdekel, mert nem visz előre.

Ha lesz két-három nyers adatformátum, még mindig jobb, mint ha nincs semmi, és még mindig jobb a jelenlegi helyzetnél. De ettől függetlenül törekedni kell arra, hogy egy legyen.

Igény van, erre jó példa az árukereső. Lehet, hogy az ő formátumukat kell használni áruk esetén, de lehet, hogy más jobbat tud kitalálni, ezt majd eldönti az élet.
43

Nem

janoszen · 2016. Szep. 21. (Sze), 14.56
Ez nem magyar hozzaallas kerdese, hanem realitasok kerdese. Lasd be, hogy az altalad javasolt megoldas akkor es csak akkor viszi elobbre a vilagot, ha van, aki moge all. Es egy tech demo max erdekesseg szamba megy, az a melo legkisebb resze.

A melo oroszlanresze az, hogy meg kell irni a specifikaciokat es ezt a piaci szereplokkel el kell fogadtatni. En nem latok jelenleg senkit, aki ebben gondolkozna es ezen munkalkodna. Ha Te igen, akkor en szivesen elolvasnam a keszulo specifikaciot.
45

Így van

Hidvégi Gábor · 2016. Szep. 21. (Sze), 16.17
Tökéletesen igazad van, és ezekkel én is tisztában vagyok. Amit kitaláltam, annak több pozitív vonzata van, jelentősen leegyszerűsíti a fejlesztői munkát, és még akkor is hasznos, ha a szemantikus része nem jön össze.

Tehát már akkor is előrébb viszi a világot, ha a fejlesztők mögéállnak, mert kevesebbet kell dolgozniuk és egyszerűbb lesz a karbantartás.
47

Ha ez a célod, akkor én a

inf3rno · 2016. Szep. 21. (Sze), 16.23
Ha ez a célod, akkor én a helyedben elsősorban az XSL megszerettetésével foglalkoznék, mert az én tapasztalatom, hogy pocsék eszköz. Nehéz debuggolni, nem kapok normális hibaüzenteket, ha mondjuk böngészőben akarom használni. Nehéz fejleszteni, mert minden xml tag-ekben van, és így tovább. Nekem kényelmetlen, de szívesen látnék cikket róla, hogy hogyan érdemes XSL-t programozni, és mik a fő buktatói.
10

Alapvetően a nyers adatokkal

inf3rno · 2016. Szep. 20. (K), 20.29
Alapvetően a nyers adatokkal dolgozunk, amikben ott van minden meta információ.


Csak egy példa:

<weboldal oldal_cim="Tárolóegységek, hangtalan PC-k – címlap" oldal_url="./">
<tartalom tipus="cimlap">
<promokep href="termek.html?azonosito=kingspec_512_c2_sata3">
<nagy_felirat>Legjobb ár/érték</nagy_felirat>
<kis_felirat>512GB SSD – 30 000,- Ft</kis_felirat>
<kep href="i/kingspec_promo.jpg"></kep>
</promokep>
</tartalom>
<termekek href="http://hidvegi.net/termekek_ssd.xml"></termekek>
<termekek href="http://hidvegi.net/termekek_microsd.xml"></termekek>
<termekek href="http://hidvegi.net/termekek_pendrive.xml"></termekek>
<termekek href="http://hidvegi.net/termekek_minipc.xml"></termekek>
<termekek href="http://hidvegi.net/termekek_egyeb.xml"></termekek>
<jellemzok href="http://hidvegi.net/jellemzok.xml"></jellemzok>
</weboldal>
Hol látunk itt "meta információt"?
11

+1

janoszen · 2016. Szep. 20. (K), 20.32
+1, ezzel az XML-el rajtad es az altalad irt XSLT-n kivul a kutya nem tud mit kezdeni.
13

Adatok

Hidvégi Gábor · 2016. Szep. 20. (K), 20.43
Egy weboldal két részből áll, az első, amit itt látsz, az, ami leírja, az adott lapnak milyen adatai vannak, a másik pedig a felhasznált adatfolyamok.

Jelen esetben a tartalom típusa "cimlap", azon belül van egy "promokep", és annak a tulajdonságai.

Az adatfolyamok a "termekek"-en belül lévő xml fájlok, ezeket használja fel például a menü kirajzolásához.
15

Értelmezni

janoszen · 2016. Szep. 20. (K), 20.47
Jó, de ezt hogy fogja bárki értelmezni rajtad kívül? Tök jo, szemantikus. Egy humanoidnak. És ez jó. De ez nem alkalmas önállóan gépi adatfeldolgozásra, hacsak kifejezetten erre nem írsz értelmezőt.

Attól, hogy XML, nem lesz mágikus módon egyszer csak gépi úton értelmezhető. Ahhoz kell valaki, aki egy fordítót ír (XSLT) az adott célplatform számára.
18

XML

Hidvégi Gábor · 2016. Szep. 20. (K), 20.55
Az XML azért jó, mert jól definiált adatformátum, egy függvényhívással be lehet olvasni bármely nyelven, és azonnal lehet vele dolgozni. Hogy a benne lévő információt ki és hogyan értelmezi, az már legyen az ő saját gondja.
21

HTML

janoszen · 2016. Szep. 20. (K), 21.12
JSONra is van sémadefiníció, ez nem teszi az XML-t különlegessé.

Lásd lentebb, ez önmagában még nem tesz a jövő technológiájává. Ahhoz valakinek bele kell tennie az energiát, hogy elfogadott szabványok legyenek az adatleírásra, ami jelenleg hiányzik.
23

XML

Hidvégi Gábor · 2016. Szep. 20. (K), 21.18
Az XML-t az teszi különlegessé, hogy van hozzá egy szabványos, lezárt és elfogadott transzformációs nyelv, az XSLT, amit minden programozási nyelv támogat, kisebb részben pedig az, hogy fél dimenzióval többet tud, mint a JSON.
36

XPATH

Hidvégi Gábor · 2016. Szep. 21. (Sze), 10.23
Az XML transzformációk egyik legnagyobb kényelmi funkciója az XPATH, aminek a segítségével DOM node-okat kereshetünk.

Képzeld el a következő JSON-t:
var minden_termek = [
  {
    kategoria: 'microsd',
    termekek: [
      {azonosito: 'samsung_32gb'},
      {azonosito: 'samsung_64gb'}
    ]
  },
  {
    kategoria: 'pendrive',
    termekek: [
      {azonosito: 'samsung_32gb'},
      {azonosito: 'samsung_64gb'}
    ]
  }
];

Egy nagyjából ekvivalens XML-ben megkeresni a 'samsung_32gb' azonosítójú csomópontokat, amelyek kategóriája 'pendrive' XPATH segítségével:
<xsl:variable name="termek" select="$minden_termek[@kategoria = $kategoria]/*[@azonosito = $azonosito]" />

JS-ben minden ilyen kereséshez saját függvényt kéne írni, és ez egy piszok egyszerű XPATH.
37

Egy nagyjából ekvivalens

inf3rno · 2016. Szep. 21. (Sze), 13.10
Egy nagyjából ekvivalens XML-ben megkeresni a 'samsung_32gb' azonosítójú csomópontokat, amelyek kategóriája 'pendrive' XPATH segítségével...


Mikor van ilyen keresésre szükség?
41

Mindig

Hidvégi Gábor · 2016. Szep. 21. (Sze), 14.26
Ha kapsz egy adathalmazt, amit fel kell dolgozni – bármilyen formában: XML, JSON, SQL, noSQL –, akkor mindig. Legegyszerűbb példa, amikor azonosító alapján szeretnéd egy termék tulajdonságait megtalálni.
46

Ha én erre kényszerülök,

inf3rno · 2016. Szep. 21. (Sze), 16.18
Ha én erre kényszerülök, akkor a szerveren szoktam lekérni az adatbázisból mondjuk SQL-el, nem átküldöm a kliensre a teljes adatbázist, és ott oldom meg. Ez a fajta megközelítés csak nagyon kis oldalaknál működik, és azoknál is probléma lehet, ha menet közben a szerveren frissíted az adatokat, de a kliens még mindig a régi adatokból generált xml-el dolgozik. Nem járható út, hogy a keresést, szűrést, rendezést, viewmodel készítést a kliensen csinálod. Nem is gondoltam rá, hogy te tényleg így gondolod, azt hittem, hogy janoszen értett félre...
48

Egyszerűbb

Hidvégi Gábor · 2016. Szep. 21. (Sze), 16.42
Ez ennél egyszerűbb. Van például a 10-es hozzászólásodban az a kódrészlet, annak a második sorában van egy ilyen: <tartalom tipus="cimlap">, ez egy választó, ahol a típustól függően más-más sablonból generálom a HTML-t.
49

Ez teljesen rendben van. És

inf3rno · 2016. Szep. 21. (Sze), 17.03
Ez teljesen rendben van. És hogyan szűröd az adatokat, ha mondjuk több ezer terméked van rengeteg kategóriával, és a kliens csak mondjuk az olyan Samsung SSD-kre kíváncsi belőlük, amik 15k-nál drágábbak? Vagy mondjuk csak az olyan termékek érdeklik, amik 10-20k közötti összegbe kerülnek, mert Karácsonyra akar venni valamit a gyerekének, és még nem tudja, hogy mit?
50

Egyszerű

Hidvégi Gábor · 2016. Szep. 21. (Sze), 18.44
Az oldal adatforrása lehet egy php is, ami XML-t ad vissza a kapott paramétereknek megfelelően.

A jelenlegi demó oldalamon statikus fájlok vannak, mert oda bőven jók, és a kód is úgy dolgozik, hogy azokból nyeri az adatokat.
51

Ja értem, akkor ezek szerint

inf3rno · 2016. Szep. 21. (Sze), 21.03
Ja értem, akkor ezek szerint te is szerver oldalon szűröd az adatokat. Félreérthető vagy, úgy jött le, hogy átküldesz mindent XML-ben, aztán XSL-el szűröd az adatokat.
52

Feladatfüggő

Hidvégi Gábor · 2016. Szep. 22. (Cs), 07.24
Kis adatmennyiségnél simán lehet sablonban szűrni.
53

Persze, én is így látom.

inf3rno · 2016. Szep. 22. (Cs), 20.24
Persze, én is így látom. Nagynál viszont muszáj adatbázissal. Érdekes egyébként a technikád, mert teljesen REST kompatibilis és szemben a JSON alapú dolgokkal, ennél a böngésző tud REST kliens lenni.
54

Bizony

Hidvégi Gábor · 2016. Szep. 23. (P), 08.58
Elég sokáig kotlottam rajta, ki van ez találva : ) Sok finomságot még nem is írtam le, mert akkor nem maradna a cikkben semmi újdonság.
55

cikk?

Pepita · 2016. Szep. 23. (P), 20.54
Bocsi, úgy tűnik ez mostanában a vessző paripám: Hol VAN a cikk?
Szerintem ez is, és Jánosé is sokakat érdekel(ne).
Ádám, pls turbo üzemmód és / vagy több szerkesztő!!
56

Lesz

Hidvégi Gábor · 2016. Szep. 24. (Szo), 12.06
Óriási a téma, még sokmindent nekem is helyre kell tennem a fejemben. Jelenleg példaprogramokat készítek, amelyekkel demonstrálni tudom, mire lehet felhasználni azt, amit kitaláltam.
25

Hogy a benne lévő információt

inf3rno · 2016. Szep. 20. (K), 21.24
Hogy a benne lévő információt ki és hogyan értelmezi, az már legyen az ő saját gondja.


Nyilván a nehéz problémák megoldását jobb áthárítani másokra. :-)
24

Persze látom, hasonló XML-ek

inf3rno · 2016. Szep. 20. (K), 21.23
Persze látom, hasonló XML-ek azok is.

A gond az vele, hogy a te XSL klienseden kívül semmi más nem tudja gépileg feldolgozni. Erre szoktak tipikusan saját MIME típust pl: link, link használni, amit csak egy webszolgáltatás használ, és az arra specifikus kliensek tudják kezelni. Ezen felül esetleg ráveheted a google-t, facebook-ot, twitter-t, hogy támogassák a te MIME típusodat, de erre kicsi az esélyed.

A te megoldásodban nincsen semmi általános, és a szemantikus web pont arról szólna, hogy valamilyen általános megoldást alkalmazzunk, amit egységesen tudnak a kliensek, nem kell tanítgatni őket rá. Erre általában RDF-et szoktak használni, és valamilyen szabvány RDF vocab-ot. A gond most éppen az, ahogy janoszen is felvázolta, hogy szaporodnak a szabvány RDF vocab-ok, és széthúznak a nagy cégek ilyen téren. Így most már kénytelenek vagyunk többféle vocab-ot támogatni egyszerre, ha azt szeretnénk, hogy mindegyik cég tudja értelmezni, amit kiszolgálunk.

Szerintem az a fő probléma itt, hogy minden vocab a valóság egy kis szeletkéjét írja le egy bizonyos nézőpontból. Még ha azonos fogalmakat is írnak le, akkor is az eltérő nézőpontok miatt nem lesznek teljesen egyformák. Én dolgozok valamin, ami megoldhatja ezt a problémát, de az még sok idő, meg sok munka, már ha egyáltalán megcsinálom...
4

Probléma

Hidvégi Gábor · 2016. Szep. 20. (K), 18.58
számomra kérdéses, hogy pontosan mi az a probléma amit megold
Szétválasztja az adatokat a megjelenítési formájuktól. Ez ugyanaz, mint ahogy a javascriptet különválasztjuk a HTML-től, a stílusokat a HTML-től.
7

Probléma

janoszen · 2016. Szep. 20. (K), 20.23
Ez nem egy probléma, hanem a választott megoldás jellemzője. Mi az a probléma, amit megold? Értsd: kinek lesz ettől könnyebb az élete és miért?
14

Nagyjából három-négymilliárd

Hidvégi Gábor · 2016. Szep. 20. (K), 20.47
Nagyjából három-négymilliárd embernek lesz könnyebb az élete, akik interneteznek.

Ha minden website adat alapú lenne, akkor a weben lévő információk összehasonlíthatóak lennének. Kedvenc keresődbe beírhatnád, hogy "50 km-en belül legolcsóbb Samsung Galaxy A3 mobiltelefon kiszállítással", és tizedmásodpercen belül kidobná azt az egy találatot. Most neked mennek el óráid, mire összehalászod ezt az információt.
16

Nem

janoszen · 2016. Szep. 20. (K), 20.52
Akkor lenne igazad, ha a weben mindenki hajlandó lenne megegyezni egy közös adatformátumban, amit termékek leírására használ. De ez idealista fantázia, a világ nem így működik. Úgy, hogy közöm nincs termékekhez vagy webshopokhoz, fejből tudok 3 konkurens adatformátumot mondani, amiből 2 XML-es. Plusz a Te, egyedi, senki más által nem ismert formátumod.

Attól, hogy XML valami, nem lesz automatikusan gépi úton értelmezhető. Ahhoz kell az, hogy valaki megmondja a benne levő mezőkről, hogy mi a céljuk, milyen adatot tartalmaznak. Na ez a metaadat.

Kicsit olyan érzésem van, hogy találtál egy technológiát, ami a maga nemében tök életképes, és most keresel egy célt, hogy mivel tudnád megindokolni, hogy ez a jövő. De nem ez. Az XML csak egy eszköz, adatok strukturált leírására, semmi több. Nem nyilatkozik az adatok szerepéről, céljáról. Ahhoz kell egy specifikáció, egy XSL, és kell az, hogy a világ, vagy legalább az üzleti partnereid hajlandóak legyenek használni.
19

Akkor fel kell használni a

Hidvégi Gábor · 2016. Szep. 20. (K), 20.57
Akkor fel kell használni a schema.org adatbázisát, vagy kell csinálni egy hasonlót.
20

Pontosan

janoszen · 2016. Szep. 20. (K), 21.00
Pontosan erről van szó! Ha azt szeretnéd, hogy ez legyen a jövő, akkor Neked, vagy valakinek a hozzád hasonló gondolkodásúak közül, kell írnia egy XSL-t és a hozzá való dokumentációt a schema.org XML-ben való ábrázolására.

Majd ha ez megvan, ezt el is kell fogadtatni legalább egy fő piaci szereplővel, mert ahhoz, hogy ez legyen a jövő, azt használnia is kell valakinek.

Ha ez mind megvan, akkor elérted, hogy azt mondhasd, hogy ez a jövő. Addig ez csak egy, a maga nemében érdekes és izgalmas, viewmodel megoldás, semmi több.
22

Így van

Hidvégi Gábor · 2016. Szep. 20. (K), 21.16
Azért vagyok itt, hogy előbb megmutassam a szakmának, aztán megyek tovább. Ez egy út, aki akar, velem tart. Hogy mi sül ki belőle, azt nem tudom, de abban biztos vagyok, hogy ez vagy valami hasonló lesz a végső megoldás.
26

Hát ez a fajta megoldás talán

inf3rno · 2016. Szep. 20. (K), 21.33
Hát ez a fajta megoldás talán 5+ éve elfogadott volt a szakmában, manapság megyünk el a REST + RDF + szabvány vocab-ok felé, legalábbis én így szeretném. ;-) A gond szerintem leginkább ott van, hogy nehéz egy szolgáltatáshoz megfelelő vocab-ot találni, ami tényleg minden részét lefedi, illetve nagyon nehéz ilyen általános vocab-okat előállítani. Nem véletlenül van azonos problémára többféle vocab, egyik sem tökéletes.
27

Mondj egy olyan szakmát az

BlaZe · 2016. Szep. 20. (K), 21.54
Mondj egy olyan szakmát az emberiség történelmében, amiben volt végső megoldás. Állomások vannak, és folyamatos fejlődés. A folyamatos fejlődés pedig gátja egy akármilyen örökké tartó és teljesen univerzális megoldás létrejöttének. Ez különösen igaz az informatikában. Szerintem ez utópisztikus cél. A legjobb projekteket is forkolják githubon :)
29

A legjobb projekteket is

inf3rno · 2016. Szep. 20. (K), 23.32
A legjobb projekteket is forkolják githubon.


Ez jó, ezt be lehet tenni az idézendő aranyköpések közé. Mondjuk az ilyen alap igazságoknak is lehetne egy menüpontot csinálni. :-)
31

Automatikus

janoszen · 2016. Szep. 21. (Sze), 09.04
Figyelj, borzasztó érdekes téma, én rengeteget tanultam ebből a kis beszélgetésből (pl. hogy az XSLT tényleg működik, és még a Facebook is feldolgozza), de ettől függetlenül szerintem helyén kell kezelni a kérdést. A jövő az, ami mögé elég sok ember beáll, az XML pedig nem annak néz ki. Az XSD 1.1 évek óta várat magára, az XForms és csomó hasonló, szabványosodás irányába menő projekt meghalt és az XML körüli tooling pedig hiányos, és ami van, az méregdrága és platformfüggő. Ahhoz, hogy ebből legyen valami, rengeteg embernek rengeteg energiát kell tenni a szabványosítási munkába és az ahhoz tartozó toolingba, ehhez messze nem elég egy tech demo. Nem tudom, hogy van-e e körül közösség, mert szerintem ezt a harcot egyedül nem fogod tudni megvívni.
33

Hogy sikerül-e vagy sem, az

Hidvégi Gábor · 2016. Szep. 21. (Sze), 09.12
Hogy sikerül-e vagy sem, az majd kiderül, de ha meg sem próbálom, akkor biztosan nem.

Azt ne felejtsd el, hogy mivel ez az egész a HTML "alatt" van, és jelenleg nincs versenytársa, jóval könnyebb a dolog, mint ha valaki egy n-edik schema.org-hoz hasonló szintaktikát fejlesztene.
39

+1, én mondjuk nem tanultam

inf3rno · 2016. Szep. 21. (Sze), 13.34
+1, én mondjuk nem tanultam semmit, mert már foglalkoztam hasonló XSL-es megoldással sok éve. A gond ezekkel az, hogy az XML felett eljárt az idő, most a JSON korszakát éljük.

Amit én szeretnék, hogy szép lassan átcsússzunk a JSON-LD korszakába, bár ennek jóval magasabb a belépési küszöbe, mint a JSON-nak, de szemantikusan egyszerűbben le lehet vele írni az adatot, mint XML-el, illetve gráfot is lehet vele küldeni, nem csak hierarchiát.
6

Működési elv

Hidvégi Gábor · 2016. Szep. 20. (K), 19.26
A kérés alapján először szerveroldalon összeállítunk egy XML stringet, ami tartalmazza az összes szükséges nyers adatot. Ezt akár elmenthetjük fájlba, azaz gyorsítótárként használhatjuk, ha nem sokat változik.

Első kérésnél a transzformációt a szerveroldalon végezzük el, például HTML-t vagy RSS-t állítunk belőle elő XML stíluslap segítségével, majd kiküldjük a kliensen.

Amennyiben lehetséges, a kliensen (böngészőben) javascripttel ellenőrizzük, hogy mire képes, és a kapott információt elhelyezzük egy süteményben. A következő kéréskor már szerveroldalról – amennyiben az alkalmazáslogika megengedi, tehát ez opcionális – már XML-t küldhetünk a kliensnek, ami előállítja a HTML-t.
28

értem én ezt az egészet, meg

szabo.b.gabor · 2016. Szep. 20. (K), 22.30
értem én ezt az egészet, meg igazából mindenki ezt szeretné, ilyen olyan úton. én pl json és Angular fan vagyok épp, ami igazából tök ugyanez (már ha nem sértelek meg, Gábor (: ). és azért vegyük észre, hogy a weboldalak mostanában elég interaktívak, úgyhogy valamiféle js-re úgyis szükség lesz, akkor minek használjunk mást?

és legfőképp
http://hidvegi.net/aruhaz.xsl

én úgy hiszem, hogy programozzon xsl-t az akinek két anyja van. én biztos, hogy bottal sem nyúlnék hozzá (: komolyan nem embernek való.

ez a közös leíró cucc létrehozása is elég kemény dió, lehet hogy NP-teljes :D
30

Nagyjából ez a véleményem

inf3rno · 2016. Szep. 20. (K), 23.36
Nagyjából ez a véleményem nekem is, én próbáltam XSL-el dolgozni, nem ment, de persze lehet, hogy bennem van a hiba, vagy egyszerűen csak a hozzá való eszközök voltak silányak debuggoláshoz, teszteléshez, és így tovább. A js-el való fejlesztést én is szeretem, de ez is olyan dolog, hogy én imádom a js-t, és ha csak lehet azzal foglalkozok szívesen más nyelvek helyett kliens és szerver oldalon is.

A közös leíró cucc fejlesztését Gábor másokra hárította. Nyilván nem véletlenül. Az a probléma valószínűleg meghaladja az itt jelenlévők kapacitását.
34

Nem hárítottam én senkire

Hidvégi Gábor · 2016. Szep. 21. (Sze), 09.16
Nem hárítottam én senkire semmit, hanem eddig jutottam: van egy kész, működő koncepcióm, ami felhasználásra alkalmas. El kell készíteni az objektumok leírását, és meg is van.
35

Végül is mindegy, a lényeg

szabo.b.gabor · 2016. Szep. 21. (Sze), 10.04
Végül is mindegy, a lényeg itt annyi, hogy jó lenne egy adat leíró szabvány. aztán, hogy ebből xml + xsl készít html-t / megfelelően sorba rakott kiskutyákat, vagy json + js az már lényegtelen.

Kik csinálják meg mindezt?
iparági szereplők, kormányzat, közösség? vagy ezek összefogva?

hogyan lehet kezelni a különböző nézőpontokat, vagy akár csak ugyanannak az adathalmaznak a más más részhalmazait?

hogyan lehet az egészet kezelhető módon fenntartani?

van-e tényleges igény rá?

valószínűleg egy részterületen kellene sikereket elérni, és ha ott működik jól, akkor már nagyobb hajlandósággal ugranak rá mások.

tudom ajánlani a biztosítási szektort (: sok szereplő dolgozik nagyjából ugyanazokkal az adatokkal. ha ott átviszed, van remény.
40

Erre azért vannak létező

inf3rno · 2016. Szep. 21. (Sze), 13.45
Erre azért vannak létező megoldások, van rengeteg RDF formátumunk, amik képesek szabványos módon metaadatokat kötni az adathoz, plusz van RDFa, ha ez valakinek nem tetszene. Van egy csomó RDF vocab-unk, amik felsorolják a szakszavakat, meg megadják azok egymáshoz való viszonyát (mi tulajdonság, mi típus/osztály).

A gond leginkább az, hogy nehéz megfelelő probléma-specifikus RDF vocab-ot találni, és a schema.org vagy az opengraph nem fed le csak néhány szakterületet, pl közösségi oldalak, webshopok, eseményszervezés, stb. Szóval ha mondjuk fizikával kapcsolatban akarsz publikálni valamit, és szemantikusan kereshetőre szeretnéd megcsinálni, akkor nem lesz olyan vocab-od, amiben benne lesznek a fizikával kapcsolatos szakszavak (na jó, van valami kezdetleges ehhez is). Ehhez az egészhez össze kellene szedni az egész emberiség tudását minden fogalommal, szakszóval, csinálni belőle egy vagy több vocab-ot, és azokra hivatkozni, amikor szemantikusan keresünk, vagy amikor metaadatot kötünk adathoz. Nagyjából ez az, amire nincsen kapacitás, és aminek kevesebb, mint 0.1%-át adja a schema.org és hasonló megoldások. A wikipedia-nak, illetve az olyan keresőknek, mint a google, bing, stb. van szerintem a legnagyobb esélyük rá, hogy használható megoldást nyújtsanak, de nem úgy tűnik, hogy komolyabban foglalkoznának a kérdéssel, mármint, hogy csinálnának egy hatalmas tudásgráfot, és ahhoz kötnék az adatot. Helyette relatív kis méretű RDF vocab-okat szórnak össze. Szerintem ez hibás megközelítés, mert az egyes szakterületek egymással összefüggenek, és ugyanazokat a fogalmakat használhatják. De persze lehet, hogy rosszul látom. :-)
38

Akkor ez micsoda? Az XML

inf3rno · 2016. Szep. 21. (Sze), 13.29
Akkor ez micsoda?

Az XML azért jó, mert jól definiált adatformátum, egy függvényhívással be lehet olvasni bármely nyelven, és azonnal lehet vele dolgozni. Hogy a benne lévő információt ki és hogyan értelmezi, az már legyen az ő saját gondja.


Pont, hogy ez lenne a szemantikus web lényege, hogy gépileg értelmezhető legyen a benne lévő információ. A te megoldásod semmivel sem jobb, mint egy hagyományos webalkalmazás, amiben json-ban mennek xml helyett ugyanígy az adatok. Mindegyikre külön parsert kell írni, ami megmondja a feldolgozó kliensnek, hogy melyik property mit jelent a json-ban vagy az xml-ben.

El kell készíteni az objektumok leírását, és meg is van.


Nem tudom feltűnt e, hogy a szakma ezzel küzd már évek, évtizedek óta? Közel sincs meg a tudásod ahhoz, hogy bármi szabványosat alkoss ebben a témában. Nem vonom kétségbe, hogy valami egyedi megoldást össze tudsz szórni, mert már megtetted, de körülbelül itt ki is fújt. Ahhoz minimum egy domain expert kell egy-egy szakterületnél, hogy valami általános modelt le tudj tenni az asztalra, amit vagy elfogad az aktuális szakterület, vagy azt mondja, hogy ezt nem így kell modellezni, és csinál másikat. Egyáltalán nem vagyok biztos benne, hogy átmegy, amiről beszélek, mert általában nem szokott...
42

A te megoldásod semmivel sem

Hidvégi Gábor · 2016. Szep. 21. (Sze), 14.31
A te megoldásod semmivel sem jobb, mint egy hagyományos webalkalmazás, amiben json-ban mennek xml helyett ugyanígy az adatok.
Az én megoldásom annyiban jobb, hogy a transzformációra már van egy szabványos és elterjedt megoldás, ami minden programozási nyelvben benne van. Ha ugyanezt egy JSON tömbbel szeretnéd megoldani, akkor neked kell leprogramoznod az átalakítást.

Közel sincs meg a tudásod ahhoz, hogy bármi szabványosat alkoss ebben a témában.
Mindenki, ugye, magából indul ki. Hogy mit sikerül kihozni belőle, az majd elválik. Csak azért nem fogom annyiban hagyni, mert bárkinek is kétségei vannak az üggyel kapcsolatban.
44

Az én megoldásom annyiban

inf3rno · 2016. Szep. 21. (Sze), 16.15
Az én megoldásom annyiban jobb, hogy a transzformációra már van egy szabványos és elterjedt megoldás, ami minden programozási nyelvben benne van. Ha ugyanezt egy JSON tömbbel szeretnéd megoldani, akkor neked kell leprogramoznod az átalakítást.


Mennyiben más, ha js-ben programozom, mintha XSL-ben? Nem igazán érzem azt, hogy kevesebbet kellene dolgoznom.

Mindenki, ugye, magából indul ki. Hogy mit sikerül kihozni belőle, az majd elválik. Csak azért nem fogom annyiban hagyni, mert bárkinek is kétségei vannak az üggyel kapcsolatban.


Én csak a realitásokból indulok ki. Azért pár éve tanulmányozom a témát ellenben veled, akinek a mai napig fogalma sem volt róla, hogy ez az egész egyáltalán probléma. Csináld nyugodtan, én nem szólok bele, de hogy a világot nem ezzel fogod megváltani, abban biztos vagyok. :-)
32

XSL

Hidvégi Gábor · 2016. Szep. 21. (Sze), 09.10
Pont ma reggel gondolkoztam azon, hogy az XSL szintaktika ugyanolyan jellegű, mint az SQL, ha az utóbbit érted, akkor menni fog a stíluslapozás is.

Mivel minden sablonozás arról szól, hogy egyik adatformátumot egy másikba transzformálod (pl. JSON -> HTML), ez a deklaratív/funkcionális stílus a leghatékonyabb.

Példa a fenti XSL-ből:

<xsl:template match="weboldal">
->
SELECT template WHERE name="weboldal";

<xsl:template match="tartalom[@tipus = 'kapcsolat']">

SELECT template WHERE name="tartalom" AND @tipus="kapcsolat";

Változó:
<xsl:variable name="termek" select="$minden_termek[@kategoria = $kategoria]/*[@azonosito = $azonosito]" />

$termek = SELECT * FROM $minden_termek WHERE @kategoria = $kategoria AND @azonosito = $azonosito;
57

konklúzió

_subi_ · 2016. Szep. 26. (H), 09.34
Szerintem az általad linkelt aruhaz.xsl választ is ad a kérdésre, hogy miért nem terjedt el ez a megoldás széles körben és miért nem is fog.

Az összes többi, egy érdekes társalgás a témáról és nem több.
58

Miért?

Hidvégi Gábor · 2016. Szep. 26. (H), 10.40
Ha nekem, kocaprogramozónak, aki két évtized alatt képtelen volt megérteni az OOP-t (ebből lehet következtetni a szellemi kapacitásomra), sikerült abszolválnom, akkor másnak miért ne sikerülhetne?
59

ez nem képesség kérdése

_subi_ · 2016. Szep. 26. (H), 11.02
Az átláthatóság szerintem nagyon fontos. Biztos vagyok benne, hogy bármilyen adatformátummal és programnyelvvel lehet dolgozni, az igazi kérdés, hogy miért tennénk ilyet (adott esetben önsanyargató módon)?

Én megértem az érveidet, egy részüket talán még el is fogadom, ugyanakkor szerintem ez messze kevés lesz az XML / XSL elterjedéséhez. Legyünk őszinték, bőven lett volna ideje bizonyítani az életképességét, de ehelyett a világ egyszerűen túlhaladt rajta.

Mindezzel együtt, becsülöm az erőfeszítésed, hogy hiszel valamiben és próbálod sikerre vinni.
60

Kifejtenéd?

Hidvégi Gábor · 2016. Szep. 26. (H), 14.09
Mi ebben az önsanyargatás? Elsőre nem világos a szintaktika? Minden új dolgot meg kell szokni, aztán rájössz, hogy mennyire egyszerű.

A sablonban nagyjából tizenöt nyelvi elemet használok: sablon definiálása, elágazás feltétel szerint, ciklus (iteráció), DOM elem létrehozása, attribútum módosítása, rendezés, változók létrehozása.

Vannak feladatok, amire a funkcionális/deklaratív stílus jobb, mint a procedurális, a sablonkezelés (és pl. az SQL) tipikusan ilyen.

Egy jó kódszínező csodákra képes, továbbá a JS-hez is készült a CoffeeScript, annak mintájára lehet készíteni az XML transzformációkhoz is valami nyelvet, ami tömörebb.
61

Innentől elég szubjetív...

_subi_ · 2016. Szep. 26. (H), 15.13
Nekem személy szerint a koncepció semelyik része sem tetszik, már önmagában az egy borzalom, ahogy a template-ben ilyen módon keveredik a logika és a megjelenítés. Ha valamihez hasonlítanom kellene, akkor talán a jóféle spagettikódra hajaz. (A spagettikód is megszokható.)

Erre mondhatod, hogy a manapság használt template rendszerek (pl. Twig, Blade) is rendelkeznek több-kevesebb logikával, és azért rosszabbak, mert... A sima JSON visszaadása és kliensoldali feldolgozása meg azért rosszabb, mert...

Engem semmiképpen sem érdemes győzködnöd. A cikkedet kíváncsian várom a témában (már csak azért is, mert becsülöm az erőfeszítésed), de ennyi. Annak, hogy a gyakorlatban az XML / XSL kombinációt használjam, nagyjából nulla az esélye, és hidd el, ez nem holmi kódszínező kérdése.