Release Pxml Fileformat V1.5

[EvilDragon]

skeezix together with cpasjuste implemented PXML into his lib_pnd (yep, every dev can use that lib and easily read out all PXML stuff).

PXML has changed slightly to be more easily read by his library, so I updated the specs.

For those who have no idea what PXML is:
It is basically a file which devs include within their games archive. The Pandora menu reads out that file and can automatically sort the game into the correct category, show descriptions or preview pictures and associate filetypes with. So basically, the user puts all his games onto the SD Card, inserts that into the Pandora, and the menu becomes automatically populated.

Download: PXML v1.5

 

[lulzfish]

Well, I had a few questions about this, but the example answered most of them.
What icon resolutions are recommended? Is animated PNG supported by any chance?

Also, is there any list of categories that should be used?

 

[dflemstr]

See in post #5 for my post, I messed up, sorry (partly due to forum bugs).

 

[lulzfish]

Maybe you could just have an attribute for the number of preview pictures?
And how's this unique id supposed to work?
Should I just make one up? Is it dependent on versioning? Would it be fine to just use "$name_$numberofsecondssinceepoch"?

 

[dflemstr]

OK, my post is kinda unstructured up there. I will probably delete it or something.
It bugs me alot that this standard isn't valid XML.
Better said, these are the problems with the standard:

1. You use specific tags for language instead of "xml:lang". This means that the menu program needs to know ALL the ISO codes in the world and look for them just to translate the menu.
Proposal: Instead of "<description><de_DE>....", PLEASE use "<description xml:lang="de_DE">...."

2. You use numbers in tags so that they can change dynamically. Why is this a bad idea? I guess that most of you understand C; this is an example with the same problem:
CODE
int main() {
loop3times {
printf("lol");
}
}

The 3 shouldn't be part of the syntax, but a variable. Otherwise, the menu app has to look for "pic1", "pic2" etc. instead of just "all the "pic"s" and then sort them by nr.
Proposal: Instead of "<previewpic><pic1>...", use "<previewpics><pic nr="1">..."

3. You put things that should only exist ONCE in tags, so that it is possible to repeat them. What if the user adds many "<standalone>" tags, with different values? Values that should only be specified once, should only be allowed to do so.
Proposal: Instead of "<PXML><icon>...", use "<PXML icon="...">..."

4. You don't use an XML namespace. This must be specified for valid XML. Just add a xmlns="" attribute to the PXML tag, with some random URL in it.

5. You use BBCode for formatting. Why? Consider, if you don't want CSS, to use <i>-Tags etc. at least.

My proposition would be to set the standard to something like this:
CODE

<PXML xmlns="http://openpandora.org/namespaces/PXML" unique_id="123shaboo" standalone="yes" icon="hellollo.png" exec="/bin/bash -c 'echo hellollo'">

<title xml:lang="en_US">Hellollo</title>
<title xml:lang="de_DE">Hallollo</title>
<title xml:lang="sv_SE">Hejej</title>

<description xml:lang="en_US">This is a long description for the app. Why does it use BBCode? Well, nothing is perfect, I guess. Look into CSS (the standard) some other time.</description>
<description xml:lang="de_DE">Dies ist eine längere Beschreibung für das Programm. Wieso verwendet sie BBCode? Naja, nichts ist perfekt... Ihr solltet aber euch überlegen, vielleicht zu CSS herüberzugehen</description>
<description xml:lang="sv_SE">Detta är en längre beskrivning av programmet. Varför använder den BBCode? Nåja, inget är väl perfekt... Ni borde dock överväga att byta till CSS</description>

<author name="dflemstr" website="a.bc.de" />
<version major="1" minor="1" release="1" build="2" />
<previewpic>
<pic nr="1">./lol.png</pic>
</previewpic>
<!--And so on, and so on...-->
</PXML>



PLEASE take this into consideration, since it will become VERY difficult otherwise to write launchers/menu apps for this format!!

EDIT: It is VERY difficult to fight vs these forum bugs!

 

[lulzfish]

Do you really need markup in the description at all? I could see links, maybe.

 

[Dutch_Cap]

Since the forum has broken the link to the PXML definition:
CODE
http://archive.openpandora.org/cgi-bin/cfiles.cgi?0,0,0,0,45,5"

 

[EvilDragon]

According to the xml checker (http://www.cogsci.ed.ac.uk/~richard/xml-check.html), it is valid.

PLEASE take this into consideration, since it will become VERY difficult otherwise to write launchers/menu apps for this format!!

Why should it be difficult?
lib_pnd does all you need for reading in interpreting PXML already.
No need to code it yourself.

 

[Squidge]

3. You put things that should only exist ONCE in tags, so that it is possible to repeat them. What if the user

PLEASE take this into consideration, since it will become VERY difficult otherwise to write launchers/menu apps for this format!!

Your example seems inconsistent. If you want everything that should exist only once to be in the PXML tag, shouldn't 'version' be in there too? I do think this way looks a little messy however.

As for writing launchers/menu apps, all they have to do is call the routines in libpnd. Therefore they need not bother parsing any xml on there own - they simply ask libpnd to do all that work for them.

 

[hlidegp2x]

According to the xml checker (http://www.cogsci.ed.ac.uk/~richard/xml-check.html), it is valid.

PLEASE take this into consideration, since it will become VERY difficult otherwise to write launchers/menu apps for this format!!

Why should it be difficult?
lib_pnd does all you need for reading in interpreting PXML already.
No need to code it yourself.

I can understand the point given by dflemstr :
- try to use attributes for an element instead of several terminal sub-elements when their orders don't care.
CODE

<element att1="1" att2="2" att3="3"/>
and
<element att3="3" att2="2" att1="1"/>
is strictly equivalent (their schema xsd would be the same) and attributes are easy to fetch from an element

<element><sub1>1</sub1><sub2>2</sub2><sub3>3</sub3></element>
and
<element><sub3>2</sub3><sub2>2</sub2><sub1>1</sub1></element>
is not strictly equivalent (their schema xsd would be different as their orders care) and accessing the texts of the sub-elements are trickier if you plan to read it serially.


- avoid to use elements tagged as "<tag-element_N/>" instead of "<tag-element rank="N"/>". Having <picX/> is UTTERLY stupid and make the code to fetch an element trickier. Best solution :
CODE

<pics> // pics only contains pic elements so counting its sub-elements gives pictures count
<pic/> // this one being the first
<pic/> // this one being the second
...
<pic/> // etc. of course you could also add an attribute like index="N" to make their index explicitly but it isn't necessary.
</pics>



considering <title/> :

CODE

<title>
<en>xxxx</en>
<fr>yyyy</fr>
<new iso>zzzz</new iso>
</title>


your xsd schema will be incomplete as it wouldn't know about a new ISO and reject it

where as :
CODE

<titles>
<title>xxxx</title> // no lang ==> en !
<title lang="fr">yyyy</title>
<title lang="new iso">zzzz</title>
</titles>


your xsd schema won't reject it.

 

[EvilDragon]

Well, those specs have been done and included by those who actually did code lib_pnd, and it is optimized for easy working.

Why change something if it is already implemented and working?

I wish I would never post such stuff anymore, as with each thing posted, moaning starts again.
And as soon as we change it according to some other peoples wishes, moaning by some other guys starts again...

 

[Tor]

Well, I'm no heavy-duty xml programmer, but hlide's comments make sense to me.

Not that I'm going to moan much about this, as I don't expect to be much of a gamer when I get my Pandora. Presumably I will not interact much with the pxml format then.

 

[PoisonedV]

I can't comment on standards cause I know nothing about them, but I AM glad to have an organization system. I am incredibly anal about the way I store my games...

 

[dflemstr]

OK, I'm sorry to have brought this up in the way I did. It's just that I have used alot of application frameworks and utilities that use XML. XML is there for a reason, and that is that it should be possible for any application to use the data provided by the XML file, and making it easy to use a format.

I do not see what I said as moaning. I only tried to highlight problems that will happen, sooner or later, because the PXML format has alot of problems. (For example: What happens with multiple standalone tags? What if you want to associate the app with MIME types and not only extensions? How does the format handle encodings other than UTF-8 (for languages other than english)? etc) This rises alot of problems for a programmer, and for someone who would like to write a PXML file.

Most frameworks I have used so far comply to the XML standard. This makes it easy to make your own tools that support the format. Since the format is pure XML, you don't need any extra tools except an XML reader/writer to change something in that file. Any editor/library/application that supports XML can thus open the file.

This isn't possible with the current PXML file format. libxml won't even open the example file, since it isn't valid XML. Even if we have lib_pnd, what if I want to make an app in Java that writes PXML files for me? What if I want to make config files on my PC, and don't want to compile an extra libpnd.so file that I have to carry around with me?

So, please, either continue with your current format and mark it as a proprietary format since only lib_pnd can access it consistantly (and you should therefore make the format proprietary to avoid parser errors), then also make bindings for all other languages that devs might use, make it cross-platform and with wchar_t support etc,
OR adjust the format so that you don't need an extra library that you have to carry around just to open a file.

There's nothing that's "Almost XML". Either something is 100% XML compatible, or it is another format. It's not even that difficult to make something XML compatible. Heck, to write a 'reader' for a 100% valid XML format can be done in 5 min, with libraries like libxml or similar.

Ah, and BTW, for validating XML, you need a spec first, otherwise it's impossible to validate anything. The validator you, ED, linked to, doesn't take an XML spec (in XSD format) and can therefore not be a validator for XML. XML isn't just a format, but a way to store data that needs a spec to work.

EDIT: The ONLY validator that is 100% compatible with the XML standard and officially supported by the World Wide Web (W3) group etc:
validator.w3.org
Without a DTD or a XSD file, this validator will recognise the file as XHTML 4.01 transitional, since thats the ONLY XML format that is allowed not to have a spec. Provide a XSD spec (that describes the format, like the provided PDF file but in "computer language" )

 

[dflemstr]

Sorry for 2 posts, but just wanted to make sure that people see this even after having marked this thread as read

I just wanted to add, that if the only reason why the pandora team doesn't create a format that is compatible with XML, is a lack of time, then why don't others make it?

I could volunteer to not only make a format that is compatible across all platforms, fully XML compatible, with a XSD spec, and with a C library function (no library needed) that can parse this file and give the result as a struct. Anyone else in the community could of course help with this.

We could even make it like this: The current PXML format continues to exist, until I release the new version (in max 3 days or so), and if I don't make it, I will stop complaining and just accept the current format.

What does everyone think about that?

 

[peca]

I wish I would never post such stuff anymore, as with each thing posted, moaning starts again.
And as soon as we change it according to some other peoples wishes, moaning by some other guys starts again...

But these moaning is still about the same things - about XML that isn't real XML or about things that have to be designed little differently in practices.

 

[Squidge]

This rises alot of problems for a programmer, and for someone who would like to write a PXML file.
There is no need to edit the PXML file directly. There are tools and libraries for both reading from and creating/modifying the PXML. It would be daft to reinvent these just because you can.

Secondly, libpnd.so isn't just for reading PXML files, it has far more functionality than that, but PXML parsing is just one of the functions it supports.

However, if you are willing to both modify the specification, and apply those modifications to the libpnd library and pxml creation tools, then I see no problem with that, and you should contact Skeezix directly for the current code base.

 

[dflemstr]

Thanks for the fast response. I guess the current codebase is at git://git.openpandora.org/pandora-libraries.git ?
Then I will make a patch, and you can decide wether it's worth it or not.

 

[peca]

dflemstr: I'm not well skilled in using XML, but I wish that PXML is well done XML in common form. It's better make it "in right way" due to easy use in any environment, programming language, XML tool or so.
I guess that your proposal is reasonable. You have my confidence, although I can't participate due lack of knowledge, experience and time.

 

[Butterman]

Well, those specs have been done and included by those who actually did code lib_pnd, and it is optimized for easy working.

Why change something if it is already implemented and working?

I wish I would never post such stuff anymore, as with each thing posted, moaning starts again.
And as soon as we change it according to some other peoples wishes, moaning by some other guys starts again...

That's a problem you're going to face when you're making a community project. Such is life. Let these guys moan. Most of us are content just reading this and knowing this stuff is all ticking away in the background.