Mae XML bron bob amser yn cael ei gamddefnyddio

Dyfeisiwyd yr iaith XML ym 1996. Nid cynt yr oedd wedi ymddangos nag yr oedd posibiliadau ei gymhwyso eisoes wedi dechrau cael eu camddeall, ac i'r dibenion yr oeddent yn ceisio ei addasu, nid dyna'r dewis gorau.

Nid yw'n or-ddweud dweud bod mwyafrif helaeth y sgemâu XML yr wyf wedi'u gweld yn ddefnydd amhriodol neu anghywir o XML. At hynny, dangosodd y defnydd hwn o XML gamddealltwriaeth sylfaenol o'r hyn oedd XML yn ei olygu.

Mae XML yn iaith farcio. Nid fformat data yw hwn. Mae'r rhan fwyaf o sgemâu XML wedi anwybyddu'r gwahaniaeth hwn yn benodol, gan ddrysu XML â fformat data, sy'n arwain yn y pen draw at gamgymeriad wrth ddewis XML oherwydd dyma'r fformat data sydd ei angen mewn gwirionedd.

Heb fynd i ormod o fanylion, mae XML yn fwyaf addas ar gyfer anodi blociau o destun gyda strwythur a metadata. Os nad gweithio gyda bloc o destun yw eich prif nod, mae'n annhebygol y gellir cyfiawnhau dewis XML.

O'r safbwynt hwn, mae ffordd syml o wirio pa mor dda y gwneir y sgema XML. Gadewch i ni gymryd fel enghraifft ddogfen yn y sgema arfaethedig a thynnu'r holl dagiau a phriodoleddau ohoni. Os nad yw'r hyn sydd ar ôl yn gwneud synnwyr (neu os oes llinell wag ar ôl), yna naill ai nid yw eich sgema wedi'i adeiladu'n gywir neu ni ddylech fod wedi defnyddio XML.

Isod byddaf yn rhoi rhai o'r enghreifftiau mwyaf cyffredin o gylchedau a adeiladwyd yn anghywir.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Yma gwelwn enghraifft o ymgais ddi-sail a rhyfedd (er yn gyffredin iawn) i fynegi geiriadur gwerth bysell syml yn XML. Os byddwch chi'n tynnu'r holl dagiau a phriodoleddau, bydd rhes wag ar ôl i chi. Yn ei hanfod, mae’r ddogfen hon, ni waeth pa mor hurt y gallai swnio, yn anodiad semantig o linell wag.

<root name="John" city="London" />

I wneud pethau'n waeth, nid anodiad semantig o linyn gwag yn unig sydd gennym yma fel ffordd afradlon o fynegi geiriadur - y tro hwn mae'r "geiriadur" wedi'i amgodio'n uniongyrchol fel priodoleddau'r elfen wraidd. Mae hyn yn gwneud y set a roddir o enwau priodoleddau ar elfen heb ei ddiffinio ac yn ddeinamig. Ar ben hynny, mae'n dangos mai'r cyfan yr oedd yr awdur eisiau ei fynegi mewn gwirionedd oedd cystrawen gwerth allweddol syml, ond yn lle hynny gwnaeth y penderfyniad hollol rhyfedd i gymhwyso XML, gan orfodi'r defnydd o un elfen wag yn syml fel rhagddodiad i ddefnyddio cystrawen priodoledd. Ac rwy’n dod ar draws cynlluniau o’r fath yn aml iawn.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

Mae hyn yn rhywbeth gwell, ond nawr am ryw reswm mae'r allweddi yn fetadata ac nid yw'r gwerthoedd. Golwg rhyfedd iawn ar eiriaduron. Os byddwch yn dileu'r holl dagiau a phriodoleddau, bydd hanner y wybodaeth yn cael ei golli.

Byddai mynegiant geiriadur cywir yn XML yn edrych rhywbeth fel hyn:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Ond os yw pobl wedi gwneud y penderfyniad rhyfedd i ddefnyddio XML fel fformat data ac yna ei ddefnyddio i drefnu geirfa, yna dylent ddeall bod yr hyn y maent yn ei wneud yn amhriodol ac nad yw'n gyfleus. Mae hefyd yn gyffredin i ddylunwyr ddewis XML ar gam i greu eu cymwysiadau. Ond hyd yn oed yn amlach, maent yn gwneud pethau'n waeth trwy ddefnyddio XML yn ddiystyr yn un o'r ffurfiau a ddisgrifir uchod, gan anwybyddu'r ffaith nad yw XML yn addas ar gyfer hyn.

Sgema XML gwaethaf? Gyda llaw, y wobr am y sgema XML gwaethaf a welais erioed, Yn cael y fformat ffeil ffurfweddu darpariaeth awtomatig ar gyfer ffonau teleffoni Polycom IP. Mae angen llwytho ffeiliau cais XML i lawr trwy TFTP, sy'n... Yn gyffredinol, dyma ddyfyniad o un ffeil o'r fath:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

Nid jôc ddrwg rhywun yw hon. Ac nid dyma fy nyfais:

• defnyddir elfennau yn syml fel rhagddodiad i atodi priodoleddau, sydd ag enwau hierarchaidd eu hunain.
• Os ydych chi am aseinio gwerthoedd i achosion lluosog o fath penodol o gofnod, rhaid i chi ddefnyddio enwau priodoleddau i wneud hyn. sydd â mynegeion.
• Yn ogystal, nodweddion sy'n dechrau gyda softkey., rhaid ei osod ar elfenau <softkey/>, priodoleddau yn dechrau gyda feature., rhaid ei osod ar elfenau <feature/> ac ati, er gwaethaf y ffaith ei fod yn edrych yn gwbl ddiangen ac ar yr olwg gyntaf yn ddiystyr.
• Ac yn olaf, pe baech yn gobeithio y byddai cydran gyntaf enw priodoledd bob amser yr un fath ag enw'r elfen - dim byd felly! Er enghraifft, nodweddion up. rhaid ei atodi i <userpreferences/>. Mympwyol, bron yn gyfan gwbl, yw'r drefn o gysylltu enwau priodoleddau ag elfennau.

Dogfennau neu ddata. Bob tro, mae rhywun yn gwneud rhywbeth rhyfedd iawn trwy geisio cymharu XML a JSON - a thrwy hynny ddangos nad ydyn nhw'n deall y naill na'r llall. Mae XML yn iaith marcio dogfen. Mae JSON yn fformat data strwythuredig, felly mae eu cymharu â'i gilydd fel ceisio cymharu cynnes â meddal.

Y cysyniad o'r gwahaniaeth rhwng dogfennau a data. Fel analog o XML, gallwn gymryd yn amodol ddogfen y gall peiriant ei darllen. Er ei fod wedi'i fwriadu i fod yn ddarllenadwy gan beiriannau, mae'n cyfeirio'n drosiadol at ddogfennau, ac o'r safbwynt hwn mewn gwirionedd mae'n debyg i ddogfennau PDF, nad ydynt yn aml yn ddarllenadwy gan beiriant.

Er enghraifft, yn XML mae trefn yr elfennau yn bwysig. Ond yn JSON, mae trefn parau gwerth allweddol o fewn gwrthrychau yn ddiystyr ac heb ei ddiffinio. Os ydych am gael geiriadur di-drefn o barau gwerth bysell, nid yw'r drefn wirioneddol y mae'r elfennau yn ymddangos yn y ffeil honno o bwys. Ond gallwch chi ffurfio llawer o wahanol fathau o ddata o'r data hwn. o ddogfennau, oherwydd bod trefn benodol yn y ddogfen. Yn drosiadol, mae'n cyfateb i ddogfen ar bapur, er nad oes ganddi ddimensiynau ffisegol, yn wahanol i allbrint neu ffeil PDF.

Mae fy enghraifft o gynrychiolaeth geiriadur XML iawn yn dangos trefn yr elfennau yn y geiriadur, yn hytrach na chynrychiolaeth JSON. Ni allaf anwybyddu'r drefn hon: mae'r llinoledd hwn yn gynhenid ​​ym model y ddogfen a fformat XML. Efallai y bydd rhai yn dewis anwybyddu'r drefn wrth ddehongli'r ddogfen XML hon, ond nid oes diben dadlau am hyn gan fod y mater y tu hwnt i gwmpas trafodaeth ar y fformat ei hun. Ar ben hynny, os gwnewch y ddogfen yn weladwy yn y porwr trwy atodi dalen arddull rhaeadru iddi, fe welwch fod elfennau'r geiriadur yn ymddangos mewn trefn benodol ac mewn dim arall.

Mewn geiriau eraill, gellir trosi geiriadur (darn o ddata strwythuredig). n amrywiol ddogfennau posibl (yn XML, PDF, papur, ac ati), lle n - nifer y cyfuniadau posibl o elfennau yn y geiriadur, ac nid ydym eto wedi ystyried newidynnau posibl eraill.

Fodd bynnag, mae hefyd yn dilyn, os ydych am drosglwyddo data yn unig, yna ni fydd defnyddio dogfen y gellir ei darllen gan beiriant ar gyfer hyn yn effeithiol. Mae'n defnyddio model, sydd yn yr achos hwn yn ddiangen; dim ond yn y ffordd y bydd yn ei rwystro. Yn ogystal, er mwyn echdynnu'r data ffynhonnell, bydd angen i chi ysgrifennu rhaglen. Go brin bod unrhyw bwynt mewn defnyddio XML ar gyfer rhywbeth na fydd yn cael ei fformatio fel dogfen ar ryw adeg (dyweder, defnyddio CSS neu XSLT, neu'r ddau), gan mai dyna'r prif reswm (os nad yr unig un) dros wneud hynny. i fodel y ddogfen.

At hynny, gan nad oes gan XML unrhyw gysyniad o rifau (neu ymadroddion Boole, neu fathau eraill o ddata), mae'r holl rifau a gynrychiolir yn y fformat hwn yn cael eu hystyried yn destun ychwanegol yn unig. Er mwyn echdynnu data, rhaid bod yn hysbys beth yw'r sgema a'i berthynas â'r data cyfatebol a fynegir. Mae angen i chi wybod hefyd pryd, yn seiliedig ar y cyd-destun, mae elfen destun benodol yn cynrychioli rhif ac y dylid ei throsi i rif, ac ati.

Felly, nid yw'r broses o dynnu data o ddogfennau XML mor wahanol i'r broses o adnabod dogfennau wedi'u sganio sy'n cynnwys, er enghraifft, tablau sy'n ffurfio llawer o dudalennau o ddata rhifiadol. Ydy, mae'n bosibl gwneud hyn mewn egwyddor, ond nid dyma'r ffordd fwyaf optimaidd, ac eithrio fel dewis olaf, pan nad oes unrhyw opsiynau eraill o gwbl. Ateb rhesymol yw dod o hyd i gopi digidol o'r data gwreiddiol nad yw wedi'i ymgorffori mewn model dogfen sy'n cyfuno'r data â'i gynrychioliad testunol penodol.

Wedi dweud hynny, nid yw'n syndod i mi o gwbl bod XML yn boblogaidd mewn busnes. Y rheswm yn union am hyn yw bod fformat y ddogfen (ar bapur) yn ddealladwy ac yn gyfarwydd i fusnes, ac maent am barhau i ddefnyddio model cyfarwydd a dealladwy. Am yr un rheswm, mae busnesau yn rhy aml yn defnyddio dogfennau PDF yn lle fformatau mwy darllenadwy gan beiriannau - oherwydd eu bod yn dal i fod ynghlwm wrth y cysyniad o dudalen argraffedig gyda maint ffisegol penodol. Mae hyn hyd yn oed yn berthnasol i ddogfennau sy'n annhebygol o gael eu hargraffu (er enghraifft, PDF 8000 tudalen o ddogfennaeth y gofrestrfa). O'r safbwynt hwn, mae'r defnydd o XML mewn busnes yn ei hanfod yn amlygiad o sgeuomorffedd. Mae pobl yn deall y syniad trosiadol o dudalen brintiedig o faint cyfyngedig, ac maent yn deall sut i greu prosesau busnes yn seiliedig ar ddogfennau printiedig. Os mai dyna'ch canllaw, mae dogfennau heb gyfyngiadau maint ffisegol y gellir eu darllen gan beiriannau - dogfennau XML - yn cynrychioli arloesedd tra'n ddogfen gyfarwydd a chyfforddus. Nid yw hyn yn eu hatal rhag parhau i fod yn ffordd anghywir a rhy sgeuomorffig o gyflwyno data.

Hyd yn hyn, yr unig sgemâu XML y gwn amdanynt y gallaf eu galw'n ddefnydd dilys o'r fformat yw XHTML a DocBook.

Ffynhonnell: hab.com