PXML.xml Spec Changes - Versions


ivanovic

Active Member
Joined
Aug 4, 2006
Messages
784
@Tempel / @milkshake:
How can I readout what the tools have put into the PND as PXML.xml? The file I made it use is looking like this:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<PXML xmlns="http://openpandora.org/namespaces/PXML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PXML_schema.xsd">

  <application id="snes9x.skeezix.alpha">

    <title lang="en_US">Snes9x4P</title>
 
    <exec command="./run.sh"/>

    <previewpics>
      <pic src="snes.png"/>
    </previewpics>

    <icon src="icon.png"/>

    <info name="Snes9x4P Dokumentation" type="text" src="README_Snes9x4X.txt"/>

    <description lang="en_US">Super Nintendo (SNES) emulator; derived from Snes9x4d (Dingoo) port.</description>
 
    <author name="snes9x team / SiENcE / skeezix / ivanovic" website="http://www.codejedi.com/"/>
 
    <version major="1" minor="39ff" release="20110214" build="1"/><!--This programs version-->
 
    <categories>
      <category name="Game"><!--category like "Games", "Graphics", "Internet" etc-->
        <subcategory name="Emulator"/><!--subcategory, like "Board Games", "Strategy", "First Person Shooters"-->
      </category>
    </categories>
 
    <clockspeed frequency="600"><!--Frequency in Hz-->

  </application>

</PXML>
So I assume something went wrong with pnd_make.sh, though I am just using the latest version from the repo for this. When extracting the pnd using unsquashfs, then the correct pnd is shown, too. So no idea what is really up there and I'd need to know how you get the info.

EDIT:
The pnd_make.sh is basically the one available in the official GIT, and the PXML.xml file looks rather similar to what genpxml.sh is creating. So if you find any issue in those, please make sure to also report them as bug report, so that it is also fixed in the upstream repos (cf http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=tree;f=testdata/scripts;hb=HEAD).
 
Code:
<pic src="snes.png"/>

Im not sure you can close your tags like that

I think you have to have close them like this

Code:
<pic src="snes.png"></pic>

EDIT:
I checked the spec it says

To write a PXML file, you also need to know the basics of writing a XML file. It boils down to the following:
If an element contains text or other elements, it needs a start-tag and an end-tag. This looks like (1)
If an element does not contain other elements or text, but only attributes, it looks like (2)
Code:
<exampleelement someattribute="something">something inside it</exampleelement> <!-- (1) -->
<exampleelement2 someattribute="something"/> <!-- (2) -->

but the pxml attached was written incorrectly according to the info that I stripped.

Code:
<pxml xmlns="http://openpandora.org/namespaces/PXML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nonamespaceschemalocation="PXML_schema.xsd">

  <application id="snes9x.skeezix.alpha">

    <title lang="en_US">Snes9x4P</title>
 
    <exec command="./run.sh">

    <previewpics>
      <pic src="snes.png">
    </pic></previewpics>

    <icon src="icon.png">

    <info name="Snes9x4P Dokumentation" type="text" src="README_Snes9x4X.txt">

    <description lang="en_US">Super Nintendo (SNES) emulator; derived from Snes9x4d (Dingoo) port.</description>
 
    <author name="snes9x team / SiENcE / skeezix / ivanovic" website="http://www.codejedi.com/">
 
    <version major="1" minor="39ff" release="20110214" build="1"><!--This programs version-->
 
    <categories>
      <category name="Game"><!--category like "Games", "Graphics", "Internet" etc-->
        <subcategory name="Emulator"><!--subcategory, like "Board Games", "Strategy", "First Person Shooters"-->
      </subcategory></category>
    </categories>
 
    <clockspeed frequency="600"><!--Frequency in Hz-->

  </clockspeed></version></author></info></icon></exec></application>
 
milkshake said:
but the pxml attached was written incorrectly according to the info that I stripped.
Again the question: how have you extracted this info? Where is it from and how can I extract this stuff myself? Those PXML files and informations are base don the official ones, so likely something is going wrong there, too. But to be able to look into *what* is wrong I have to know more. As you can see in the PXML.xml file when unsquasfs'ing the emu you will see that those are all "normal" tags that are being closed with a '/' inside them.
 
Last edited by a moderator:
I read the file using php as the pxml data is appended to the end of the binary. I search for the start and end tags using strpos then extract whats in between.

though from the terminal I think you can strip this also see this post.
 
Last edited by a moderator:
Okay, I uploaded a version where I fixed the clockspeed tag. Now it does not cause a problem with your upload site. Though it might be a good idea to fix/change the site to parse the version number "better". Currently it seems to not take "strings" inside those into account. The version number in the snes9x4p build consists of the snes9x version it is derived from (1.39 with an 'ff' appended since it is derived) followed with the date the version is from following the YYYYMMDD format, followed by a "build" number (which tends to just be '1'). So atm it looks like this:
Code:
<version major="1" minor="39ff" release="20110214" build="1"/>
The current output from your website, when putting this into the upload entry is:
snes9x4p_20110214.pnd uploaded Successfully.
Validating pnd file...
this apps version 1.0.20110214.1 is older then one on the server 1.1.1.1 ...Done!
It seems to struggle when parsing the entries with letters in them, otherwise the 2nd point would be "39ff", not "0".
 
well thats because the version should be a number and should not contain letters.

The version element
Description
The version element specifies the application version. A version element is required. It accepts the following attributes:
The major attribute specifies the major version number. This number should be 0 or more.
The minor attribute specifies the minor version number. This number should be 0 or more.
The release attribute specifies the release number. This number should be 0 or more.
The build attribute specifies what build the application is at. This number should be 0 or more.
Example

Code:
<version major="1" minor="1" release="1" build="2"/>

the version should really be the version of the .pnd not the app its derrived from.
this sort of thing has been discussed before see this thread :p
 
milkshake said:
well thats because the version should be a number and should not contain letters.

The version element
Description
The version element specifies the application version. A version element is required. It accepts the following attributes:
The major attribute specifies the major version number. This number should be 0 or more.
The minor attribute specifies the minor version number. This number should be 0 or more.
The release attribute specifies the release number. This number should be 0 or more.
The build attribute specifies what build the application is at. This number should be 0 or more.
Example

Code:
<version major="1" minor="1" release="1" build="2"/>

the version should really be the version of the .pnd not the app its derrived from.
this sort of thing has been discussed before see this thread :p
And I am currently talking with skeezix about changing the spec since letters are really common in there (and sebt3 agrees with me on this one). ;)
 
Last edited by a moderator:
ok but that would make version comparison extremely difficult if it includes a string.
I disagree with including a string in the version but we shall see.

thats why we suggested to skeezix about including an additional tag see here.
 
Last edited by a moderator:
milkshake, we are more talking about that kind of things :
<version major="0" minor="10+svn" release="218" build="1"/>
Your addenum didnt allow to specify svn revision, while allowing ascii7 does.
And by the way we work, we are mostly using lastest version + lastest svn rev ;)
 
but isn't this something that can be added into the description ? that its derived from so and so?
is this not going to make things more complicated?

for app developers to follow? especially those that do not write programs for a living?
 
OK well once these changes are outlined in the spec ill alter my site.

hmm what I could do is just ignore any strings when actually comparing the version.

example
Code:
old version
<version major="1" minor="1" release="1" build="2" />

new version
<version major="1" minor="39ff" release="20110214" build="1"

when comparing my site checks each part of the version in order starting with major so..

major: 1 - 1 => its the same
minor: 1 - 39ff => 39 is higher than 1 so we know this new version is newer, we can skip the rest of the version check.

so it could work like this yes?
 
what so I could just use strcasecmp($string1, $string2) ?

Code:
$old_minor = '1';
$new_minor = '39ff';

//Returns < 0 if str1 is less than str2; > 0 if str1 is greater than str2, and 0 if they are equal.
echo strcasecmp($old_minor, $new_minor);
//this example returns -2 because $old_minor is less than $new_minor???

will that work here? not sure if that works with ascii7 lol my heads starting to hurt lol

hmm that doesnt seem to work when I change $old_minor to 4 it outputs 1 even though 4 is less than 39ff hmm ill just stick to ignoring the non numeric charicters but allowing them to be saved into the db unless anyone can suggest a better way :p
 
ok for the time being Instead of replacing a string with 0 my site strips the numbers from it, if there are no numbers in the string it replaces the string with 0.
so your app has now been updated on my test site :)

obviously if the spec changes I can look into altering my script but until then im sticking with the current spec.
 
also I don't think adding the date into the version is a good idea.
This also makes version checking difficult.
 
The way Ivanovic put the date - as YYYYMMDD - is actually perfect for version checking, since a more recent date will always appear as a higher number than an older date.

I'm in favour of string version numbers, though I feel like a single string of "1.39ff.20110214.1" would be better than having separate major, minor, release, build values (since it allows an arbitrary number of dots). But that's just me; you guys make whatever changes to the PXML spec, and milkshake and I will make sure that change gets reflected in the repo spec and our software.
 
the only reason I say it makes version checking difficult is if someone uses a different date format, YYYYMMDD is perfect I guess :p but whats the point when we can just use the date of when it was uploaded (which we already store in the db)

and even more to the point keeping version as numbers only is nice clean and simple anything else can just be added to the description, its not that difficult to write in the description "this app derives from Snes9x4P svn blah blah??
 
Last night I sent skeezix the updated and working PXML_schema.xsd file. A basic change in the specification is that each version field is required to allow the following: a-z, A-Z, 0-9, '+', '-'
I hope to update the wiki pages and whatnot, soon. To have the file validate nicely you also have to follow rather strict coding guidelines, which is a result of the design of PXML. Sadly W3C conform validators are rather strict in what they accept as specification. Either it could accept only *one* entry for <title> and <description> but allow you to place the entries for <version>, <author> and whatnot else in the order you like, or you can use several <title> and <description> (and with this allow translations of those) tags but enforce a specific order for the items in the <application> block. Yesterday we decided that, to have the file validate, it would be sane to enforce the fixed order.

Here is the resulting work:
The schema definition: http://pastebin.com/TGDX88pn
A plaintext file describing the schema in coder understandable terms even if you don't understand xml schema definitions: http://pastebin.com/tgADfhnk

I hope to be able to update the wiki pages soon based on this setup and specs. I will also try to find files to update in the official repo, but have *no* idea when I'll manage to do so. Skeezix already got an update genpxml.sh script. I also want to add this validation to pnd_make.sh as optional step (if xmllint is found on the system and non critical, so validation failing won't stop the rest). Later on this stuff will, in recent version, also end in the SDKs (crosscompiler).
 
I've updated the repo spec to match. milkshake, let me know when you update to this version.

Are there any consistent rules we can follow for ordering version numbers? With just basic string comparison, there's the problem that "2" > "10". Python has some built-in version number comparison tools, and I intend to use them, but I presume milkshake will have to use something different that might not behave the same way. If we have some sorting rules, we can hopefully all implement the same ones.
 
Back
Top