Xnfo : Demoscene information standardization using XML - Pre-release
category: general [glöplog]
http://xnfo.sf.net
Xnfo is a project which goal is to create a XML model for demoscene information. First goal is production and party competition support. Here is a prerelease of the different elements of the project, for feedback.
Have a look at the project website (and at the introduction).
As pouet could support the system, comments from its community are really welcome.
Also comments from demoparty orgas are also very welcome :)
Xnfo is a project which goal is to create a XML model for demoscene information. First goal is production and party competition support. Here is a prerelease of the different elements of the project, for feedback.
Have a look at the project website (and at the introduction).
As pouet could support the system, comments from its community are really welcome.
Also comments from demoparty orgas are also very welcome :)
there is not even support for an Ascii Logo :(
uhm, i dont get the point and the documentation is quite odd i must say for being an xml spec.
whats the point? - and for once i'll agree with lator... the documentation seems rather vague
Sorry for the documentation, it's not really concreete, you should look at the examples and the quick guide.
For ascii logo, it's better to let it in the nfo, Xnfo is not really readable for a humans ;)
Some possible use scenarios can be found here : http://xnfo.sourceforge.net/doc/xnfo-userscenarios.html, but it's just a start.
Xnfo is just about creating a open/common/standard information structure for demoscene.
For ascii logo, it's better to let it in the nfo, Xnfo is not really readable for a humans ;)
Some possible use scenarios can be found here : http://xnfo.sourceforge.net/doc/xnfo-userscenarios.html, but it's just a start.
Xnfo is just about creating a open/common/standard information structure for demoscene.
file_id.diz
plain text dammit, plain text!!
who needs standards for information exchange ??
who needs standards for information exchange ??
Who needs American Standard Code for Information Interchange?
sanx: i think you should re-read one of the main rules of xml-design :-D It should be readable for (certain) humans.. But serious, WHAT is the point? Is it supposed to be put in the rar/tar.gz/zip/whatever? Is it supposed to be used on the various demo-sites (then it's obviously not needed, since all of the are pretty well organized)? Is it supposed to replace file_id.diz? I don't see a point for this xml-data...
First, thanks for the feedback.
I'm going to re-read my XML design handbook ;)
Yes it's supposed to be in archive, and/or outside. It's suposed to stay on your hard disk while the archive stays on scene.org. It could be sent to pouet/scenemusic to submit a production, or extracted from pouet/... and be on your hard drive. It could be outside the archive in a directory on scene.org, that you download when party productions are uploaded, and let a software automatically download productions for you, and run it for you.
It could be on your website for keeping an uptodate version of the demo. It can be on your website (or diskmag) and be your selection or favorite demos of all time (or even the scene.org award selection).
Sure all can already be done without xnfo, but it's not well done (some prod are quite badly submitted), and it takes time...
The problem of file_id.diz, or plain text, is parsing.
I'm sure any one of you can do it easily, but as XML is an industry standard, the parsing apis are standard, and it takes about 2 minutes to get information from a file.
For explaining what it can offer, it seems that I'll have to work on it. I first concentrated on party productions and release, but there is some other ways to use it.
I'm going to re-read my XML design handbook ;)
Yes it's supposed to be in archive, and/or outside. It's suposed to stay on your hard disk while the archive stays on scene.org. It could be sent to pouet/scenemusic to submit a production, or extracted from pouet/... and be on your hard drive. It could be outside the archive in a directory on scene.org, that you download when party productions are uploaded, and let a software automatically download productions for you, and run it for you.
It could be on your website for keeping an uptodate version of the demo. It can be on your website (or diskmag) and be your selection or favorite demos of all time (or even the scene.org award selection).
Sure all can already be done without xnfo, but it's not well done (some prod are quite badly submitted), and it takes time...
The problem of file_id.diz, or plain text, is parsing.
I'm sure any one of you can do it easily, but as XML is an industry standard, the parsing apis are standard, and it takes about 2 minutes to get information from a file.
For explaining what it can offer, it seems that I'll have to work on it. I first concentrated on party productions and release, but there is some other ways to use it.
some points on the actual format (to sum it up, IMHO it's totally overdesigned, and I got some suggestions on how to cure that :)
General remarks: I do think that system would have its uses; the current spec is far too ambitious and directionless though. But if it is done properly and succeeds, it would make the management of the (by now) several scene databases a lot easier. As said, you could just make an xnfo for your production ready
and submit that to pouet/scenemusic.net; scene.org currently already extracts file_id.diz'es from submitted zipfiles, and it could do so too with xnfos, making it far easier to automatically index the archive. It would also make the sceneprod-ftpsearch stuff easier if you could just ask e.g. scene.org whether something with that guid has been added and what its filename is.
- total overuse of tags. use attributes more... for example: <remix-of pouet_id="1234"><url>http://www.mygroup.org/demos/myoriginal.xnfo</url><file>myoriginal.zip</file></remix-of> should instead be <remix-of pouet_id="1234" url="http://www.mygroup.org/demos/myoriginal.xnfo" file="myoriginal.zip"/>. same goes for the version stuff etc. - no point in enclosing one-value fields in tags.
- demo/graphics/music/video etc tags: redundant. this should rather be a <production class="demo" category="in64">/whatever tag.
- greetings/messages: doesn't really belong into a release metadata file. rather support links to file_id/readme files which can and should contain that information (that also solves the ascii logo issue :)
- run: redundant. a demo should be startable without commandline arguments and the like. it only makes the spec more bulky and adds no real feature.
- plateform: make that "platform", please :)
- archive: seperate url/file attributes don't make sense. just drop the "file" attribute, getting it from the url is trivial.
- steps/wireframe/cover/remix-of/soundtrack: too specific. just do a "related-content" tag with url, xnfo-url, class and short description field and that's it.
- support/configuration: too verbose/specific. flatten that into a <remarks> plain-text-content tag and it will still be enough for everyone (or move it out of the xnfo completely and rely on readme/file_id).
- screenshots: make that a "preview" tag that is valid for all types of productions, so you can also use it for a thumbnail version of a gfx entry, a short sample from a music entry, etc. simpler and more powerful.
- format: make that an attribute of the "production"-tag and that's it.
- rank fields etc.: if the system is to really work out well, that (technically) doesn't belong into the demo-xnfo. rather, the demo-xnfo should just contain a link to a results-xnfo that is supplied by the party organizers.
- pouet_id/ojuice_id/scenemusic_id fields for the prod being described: again a technical problem. the whole system only makes sense when you can use such xnfos to add productions to pouet/scenemusic/whatever. that is, at the moment xnfo really makes sense, you can't make a complete xnfo. those fields must be queryable from outside, but they shouldn't be part of the actual xnfo file. rather, an xnfo needs some kind of GUID to be able to identify it; then you could ask a respective server whether something with that GUID is in the database and query for its id (or rather, directly an url :).
General remarks: I do think that system would have its uses; the current spec is far too ambitious and directionless though. But if it is done properly and succeeds, it would make the management of the (by now) several scene databases a lot easier. As said, you could just make an xnfo for your production ready
and submit that to pouet/scenemusic.net; scene.org currently already extracts file_id.diz'es from submitted zipfiles, and it could do so too with xnfos, making it far easier to automatically index the archive. It would also make the sceneprod-ftpsearch stuff easier if you could just ask e.g. scene.org whether something with that guid has been added and what its filename is.
rather useless.
xml is cool for tokenizing configuration-files :D
What kind of graphics card is needed to run Xnfo??
thom: that was lame
Your the expert on such matters.
how to get even more serious :-)
Hi,
Thanks ryg for these remarks. It will take time to take it in count, I'm working on it.
Some answers :
> total overuse of tags
That's clear it's really verbose, and it have to be improved.
> production as root (instead of demo/graphics/music/video)
should be ok, currently the C# model version uses inheritance for that, but it's more a hack than a design principle.
> greetings/messages
Because much of xnfo tags are optionnal, I wanted to keep it, but you're right, it's not relevant here.
> run
In fact it should be interesting for cross platform prods.
But, the most interesting use of this tag would be to set a gamma level higher for beeing shown right on the big screen. (in the compo tag).
> archive: seperate url/file
When you just have an archive filename and no url, imagine the archive is just put on scene.org. Sure if you have url you've got the filename.
> steps/wireframe/cover/remix-of/soundtrack: too specific. related-content...
Great idea.
> screenshot/and preview
I guess it has nothing to do with the first meaning of preview tag (in version).
Could you explain a little more, what do you expect as preview, and in what form...
> rank, and release stuff.
I started the design with the idea of having no information references except simple ones (like see more...) using urls. Ranking goes with competition, but the release information can belong to the production. For sure there is no way to create a complete xnfo before the release of a production, and having submitted it to databases.
Using GUID or url seems to be really good idea.
Do you have any remarks about Xnfo user scenarios and competition management in demoparties ?
Thanks again.
Thanks ryg for these remarks. It will take time to take it in count, I'm working on it.
Some answers :
> total overuse of tags
That's clear it's really verbose, and it have to be improved.
> production as root (instead of demo/graphics/music/video)
should be ok, currently the C# model version uses inheritance for that, but it's more a hack than a design principle.
> greetings/messages
Because much of xnfo tags are optionnal, I wanted to keep it, but you're right, it's not relevant here.
> run
In fact it should be interesting for cross platform prods.
But, the most interesting use of this tag would be to set a gamma level higher for beeing shown right on the big screen. (in the compo tag).
> archive: seperate url/file
When you just have an archive filename and no url, imagine the archive is just put on scene.org. Sure if you have url you've got the filename.
> steps/wireframe/cover/remix-of/soundtrack: too specific. related-content...
Great idea.
> screenshot/and preview
I guess it has nothing to do with the first meaning of preview tag (in version).
Could you explain a little more, what do you expect as preview, and in what form...
> rank, and release stuff.
I started the design with the idea of having no information references except simple ones (like see more...) using urls. Ranking goes with competition, but the release information can belong to the production. For sure there is no way to create a complete xnfo before the release of a production, and having submitted it to databases.
Using GUID or url seems to be really good idea.
Do you have any remarks about Xnfo user scenarios and competition management in demoparties ?
Thanks again.
why not:
name="rathercooldemo"
group="justanothergroup"
party="somestrangeparty"
year=7003
...
easy to parse, no DTD, no libXML
i think it's a good idea to make a standardized info file.
but i really don't see the point in using XML for this.
(remember: XML IS EVIL <- that's a fact now :)
name="rathercooldemo"
group="justanothergroup"
party="somestrangeparty"
year=7003
...
easy to parse, no DTD, no libXML
i think it's a good idea to make a standardized info file.
but i really don't see the point in using XML for this.
(remember: XML IS EVIL <- that's a fact now :)
i second mr :(
Deemage, it seems that the "XML IS EVIL" feeling is general, even if i don't agree. Maybe I did wrong starting with this technology choice.
Now Xnfo 1.1 is using XML, but for, say Xnfo 1.2, all aspects of demoscene information can be covered without more that an .INI file, it can change.
The discution will be openned ASAP.
Now it would be great, to get feedback on what information you want to see (and not to see) in such a standard.
Now Xnfo 1.1 is using XML, but for, say Xnfo 1.2, all aspects of demoscene information can be covered without more that an .INI file, it can change.
The discution will be openned ASAP.
Now it would be great, to get feedback on what information you want to see (and not to see) in such a standard.
deemage, xml is also quite easy to parse. it's the different charset stuff and all that makes it complicated.