XML retsensioon RAKK: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Tsildebe (talk | contribs)
Created page with "== XML osa retsensioon meeskonnale RAKK == ---- Taavi Sildeberg Kunnar Kukk Retsenseeritav materjal: https://wiki.itcollege.ee/index.php/RAKK == Sissejuhatus == Selles, 1. k…"
 
Tsildebe (talk | contribs)
Line 76: Line 76:
   </xsl:choose>
   </xsl:choose>


Teisenduse sügavus on asjakohane, küll võiks kasutada muutujaid, hetkel tundub, et on mindud lihtsamat teed arvestades ka xml-faili lihtsust ning väljendada näiteks teatud staatusega või olekus tegelased.  
Teisenduse sügavus on asjakohane, küll võiks kasutada muutujaid, hetkel tundub, et on mindud lihtsamat teed arvestades ka xml-faili lihtsust ning väljendada näiteks teatud staatusega või olekus tegelased.
 


== XSLT transformatsioon: Tegelaste itemite maksumus ==
== XSLT transformatsioon: Tegelaste itemite maksumus ==

Revision as of 08:06, 16 March 2014

XML osa retsensioon meeskonnale RAKK


Taavi Sildeberg Kunnar Kukk

Retsenseeritav materjal: https://wiki.itcollege.ee/index.php/RAKK

Sissejuhatus

Selles, 1. kodutöö osa retsensioonis vaatleme meeskonna RAKK tehtud andmefaili kujutletavate arvutimängutegelaste omadustega ning analüüsime nii andmefaili, skeemifaili kui ka transformatsioone. Töö lõpus anname soovitusi meeskonnale tulemuse tõstmiseks.


XML-fail

Faili eesmärk on hoida andmeid arvutimängu tegelaste kohta. XML-i kirja stiili osas on hea maitse küsimus, kas kirjutada sisu väiketähtedega või kasutada suurtähti. Siinkirjutajate isiklik eelistus on pigem kasutada väiketähti, mis teeb koodi lugemise lihtsamaks. XML-i puhul on välja kirjutatud kodeering ning see faili päises ära kirjeldatud. Hierarhia on mõistetav ning see on kergesti arusaadav. Fail on inglisekeelne, mis teeb selle lugemise universaalsemaks. <Durability> puhul võiks täpsustada atribuudiga, mis ühikutes mõõdetakse kestvust. Hetkel jääb arusaamatuks, kas ühik on millisekund, sekund, minut vm ühik.

Ühikutega jääb arusaamatuks veel teinegi element:

 <Item ID="1" Name="Gold" Cost="1">
       <Count>23443</Count>
 </Item>

Selle puhul jääb arusaamatuks, kas Cost puhul mõeldakse, et üks ühik on maksumusega 1 või on tegemist kulla kogumaksumusega. Alament Count viitaks sellele, et tegemist võib olla ühe ühiku maksumusega – koodi lugemisel jääb praegusel juhul kahetimõistetavus.

Välja arvatud need iluvead, on XML loetav ning arusaadav, samuti täidab XML ära nõude 3-l tasemel elemendile atribuutide määramisel.


XSD-fail

Skeemifaili võib leida läbimõtlematust mälukasutuses ehk XML-s omistatud väärtuste määramispiirkonnas, millega tuleks optimeerida mälukasutamist, mida praegusel juhul on retsenseerijate hinnangul liiga palju programmi jooksutamiseks reserveeritud.

 <xs:element name="Health">
   <xs:complexType>
     <xs:simpleContent>
       <xs:extension base="xs:unsignedShort">
          <xs:attribute name="Max" type="xs:unsignedShort" use="required" />
       </xs:extension>
     </xs:simpleContent>
  </xs:complexType>
 </xs:element>

Samas, XML-s on öeldud, et Health atribuut Max=“100“.

 <Health Max="100">8</Health>

See tähendab, et võiks kasutada maksimaalselt väärtust unsignedByte, mille määramispiirkond on 0...255. Hetkel, on mälu reserveeritud 0 ... 65535 ehk 216 bitti, saaks hakkama 28 bitiga. Mälukasutuse vahe on 256-kordne. Sama probleem esineb <Mana Max="100">0</Mana> puhul, mis on xsd-s samuti unisignedShort, kus saaks samuti reserveerida mälu 256-korda vähem.

Kõige täpsemini on esitatud element <Level>, mille maksimaalseks väärtuseks on unsignedByte. Retsenseerijatele jääb ka arusaamatuks, miks ei ole piiratud elemendi Inventory alamelemendi Item arvu, samuti on jäetud piiramata xs:string väärtuste puhul andmete maksimaalsed väärtused attribuudiga maxLength – tegelase nime juures ei ole see tõenäoliselt pikem kui ~200tähemärki.


XSLT teisendus: Kõikide tegelaste nimekiri

Koheselt jääb silma vastuolu väljundis, faili päises on öeldud, et väljund on XML, samas, väljundisse luuakse HTML-i. Ilmselt võib olla tegu kahe silma vahele jäänud parameetriga.

<xsl:output method="xml" indent="no"/>

Väljund on oma iseloomult lihtne, kuna XML-fail on koostatud rekursiivselt nii, et tegelane on peaelement, mille alamelemente tuleks antud juhul otsida ja teisenduses otsitakse rekursiivselt üle kõigi tegelaste nimekirja ning väljastatakse see, mis parasjagu ette jääb.

Keerukam konstruktsioon on loodud:

 <xsl:choose>
   <xsl:when test="count(Stat) > 0">
      Stat modifiers:
    <xsl:for-each select="Stat">
  • <xsl:value-of select="@Skill"/>: <xsl:value-of select="."/>
  • </xsl:for-each>
    </xsl:when>
 </xsl:choose>

Teisenduse sügavus on asjakohane, küll võiks kasutada muutujaid, hetkel tundub, et on mindud lihtsamat teed arvestades ka xml-faili lihtsust ning väljendada näiteks teatud staatusega või olekus tegelased.

XSLT transformatsioon: Tegelaste itemite maksumus

Selles transformatsioonis html-xml väljundit segi pole aetud ning väljund väljastab ka lubatult html-i. Tegemist on oma olemuselt keerukama ja nutikama transformatsiooniga kui eelmine. Transformatsioon on üldiselt õnnestunud ning tegeleb ka väärtuste arvutamisega. Hierarhia on paigas ning for-each tsüklid toimivad. Kui pisiasjade kallal norida, siis ääremärkusena seda, et on HTML5 spetsifikatsioonis kasutatav kui viimane õlekõrs, kui ei ole võimalik kasutada elementi.


Kokkuvõte

Soovitame meeskonnal kasutada aines antud võimalust oma koodi parandada, eelkõige skeemifail mälukasutuse osas (unisignedByte versus unsignedShort), parandada ära 1. transformatsiooni väljundparameeter xml-st html-ks, täpsustada koodis elementide ja parameetrite ühikud (Cost, Durability). See loob meie hinnangul eelduse ka paremaks lõppsoorituseks, kuna retsenseerimise hetkel kood maksimumi tõenäoliselt ei saaks. Soovitame ka koodi kommenteerida rohkem, mis annaks koodi lugejale ülevaate eelkõige transformatsioonide juures tehtavatel arvutustel, mis parasjagu toimub.