I searched a bit, yes it seems you are right.
But thats not the problem to change in my example


EDIT: What do you think over my next "try"?

stats_070403_1905_SO1_race10.xml

Quote from CLRS530 :

EDIT: What do you think over my next "try"?

I think that our XML format is a good starting point, so here are my thoughts:

Do you need the splits tag?

The speed value is for example 10412. Is this 104,12km/h?
Why is the time formated and the speed not?

Whould it be better to put the pit and penalty tags into the lap tags?
e.g.

Make it sense to put the yellow and blue flag also into the laps tag? I know that Insim does not send the lap number, but in my stats tool I put the flags into the current lap when the IS_FLG event is received.

I also suggest that we make mendatory infos and optional infos. For example the result or lap time is mendatory, but the speed should be optional.

I put a lap number into penaltie, pit and take over and no I don´t think it would be good to put it into lap because we have to put an empty element in every lap where you don´t need it.
Thats much better structured and you get a better and faster overview.
And why do you want the flags into the lap?
Thats only a counter of flags the player got.
Maybe you can make also a list of it. But I decided that it would be too much and isn´t needed.

The splits ad laps and penaties tags. I don´t know if you do this if you could have more entries. This should someone say how know more over XML. filur?

EDIT: I don´t formated the speed because you maybe will lost the exact number and its better to work with. It was in fact bad to do it with the time. But you can export it in hundreds of seconds with an option in my program (readflag 1 ist set in this case)

Quote from CLRS530 :

I put a lap number into penaltie, pit and take over and no I don´t think it would be good to put it into lap because we have to put an empty element in every lap where you don´t need it.

Why do we need an empty element?

Quote from CLRS530 :

Thats much better structured and you get a better and faster overview.
And why do you want the flags into the lap?

Thats only a counter of flags the player got.
Maybe you can make also a list of it. But I decided that it would be too much and isn´t needed.

I have a driver detail page where every lap of a the race is display and I want to add a flags column that shows when a racer has received a blue or caused a yellow flag.
Here is an example of the current version of a drivers detail page:
http://liveforspeed.at/?q=league/driver/detail/310

If the pit and penalty infos are childs of the lap element, it is also very easy with XPATH to get only a list of all pits of penalty tags.

Quote from CLRS530 :

The splits ad laps and penaties tags. I don´t know if you do this if you could have more entries. This should someone say how know more over XML. filur?

Yes you can have more entries, and you can get the correct tags with XPATH.

Ideas, Ideas, not compleat.
I want to know what you all think about where I'm going with this...


or we could go for something more like this.

Mhm you brought a new point in with your first idea. For some things it would be better to do it this way. BUT you have much overhead with ever the player name. Also it is harder to read (if you should read the xml file).
I prefer the second one (wich is similar to mine).
Also I think the first format would be harder to write.

You did everything as attributes. Also the users data (and why user and not player?).
There are many more tags to save, so that its too much to do it with attributes (my opinion)

I also happen to like my second more then my first. This is mainly due to the fact that it's more akin to the .lsf stats format that I had originally envisioned. In my view, I don't think that the end user will be reading the file raw. They will be using like SimpleXML to do that, or some other xml functions in their language.

Why did I use user rather then player? Well, user is shorter then player or driver, and second, what if this also supports spectators at some point, they are not players or drivers as they have no effect on the result.

The size of the file is really a non issue, seeing as they are so small in the grand scheme of things. We are using after all, XML, that pretty much the most pigged setup for any format, ever. So much mark up, for so little information, flat text files with expectations on what should go where would of been best if we really were worrying about the file size. But that is besides the point.

One thing that might be of rellevence to this discussion, i'm making a viewer application that allows watching of LFS races on a 2D overhead map and allows for replay rewinding, stats application authors may wish to support this file format although i've designed it for server side use and therefore it's main role is to provide for tiny files in order to keep an archive. The intended aim for it is to be used in stewarding, if it's good enough - which is yet to be finalised.

I've not finalised the format yet, but i'll post what i've got so far so that you can keep it in mind.


Final specification details will be available on program release which I hope to get done very soon.

This is sort of what i have in mind, should be fairly suitable for more or less complete post-race stats as well as "live" stats.

Sun_08_Apr_2007_13_25_33_+0200.xml

This thing contains quite a few redundant entries, is missing some stuff, generally unpolished and unfinished.

Incomplete rendering using templates from LFS Stats! can be viewed right here, original.

Hmm, I have some reasons against this format.

1. it looks like it want to look "professionell" in my eyes the "lfs:" is totally needless.
2. Why is there a live section. I see your idea but if you send this live you won´t send all the other data or am I wrong?
[Second Look]Ah I see it has another tag, not "lsf" is that a sort of case of? Will read something about it. But Iam confused because you have both in one file[/Second Look]
3. I don´t understand the finish section. I know that you get the data in the IS_FIN package, but I don´t see a reason why copying InSim in such an equal style, that we create a "readable package image"
4. You did it the other way then me and put flag to the lap times that also don´t get my vote because I think it will be harder to read the content if I think for example for creating a website out of it.
Ok you can do it with the flags maybe, but if I see this I think you want to do it with pit and penalties too.
Also I don´t think too many are interested in the detailed flags.
5. Thats my last point. You wrote sp1="" ... Thats ok but I would prefer a list of splits because you ever have to write 3 tags also if you only have 1. Thats not such a bad situation. But it isn´t save for future changes in LFS where you maybe get more then 3 split times. And I´m a ever for lists more then for this way like you saw before :P


Sorry that I´m so critical with this. I could have a go with it, but we are here to discuss over a format so everyone should say what he prefer

Quote from CLRS530 :

1. it looks like it want to look "professionell" in my eyes the "lfs:" is totally needless.
2. Why is there a live section. I see your idea but if you send this live you won´t send all the other data or am I wrong?
[Second Look]Ah I see it has another tag, not "lsf" is that a sort of case of? Will read something about it. But Iam confused because you have both in one file[/Second Look]

They are namespaces. For example, it's very simple to discard unknown namespaces, thus letting authors embed any kind of data without causing any trouble for a parser (since the parser never even sees data outside of known namespaces).

http://www.w3.org/TR/REC-xml-names/

Two thumbs way way up for that filur! I love it!

Quote from filur :

They are namespaces. For example, it's very simple to discard unknown namespaces, thus letting authors embed any kind of data without causing any trouble for a parser (since the parser never even sees data outside of known namespaces).

http://www.w3.org/TR/REC-xml-names/

Namespaces only make sense if other kind of data is also included in the XML file, and that is not the cause with the stats file format. If you want a valid XML file so that the parser has no problems, than a XML-Schema is the right way.
So we need no namespaces here, it only make things complicated.

As I wrote earlier in this thread I don't like abbreviations. You sometimes use full names in your example, and sometimes use abbreviations.
So always use full names like username instead of uname, or position instead of p.

Also the time should not be formated. XML is mostly read by programs so a unnecessary parsing could be avoided.

If the flag tags have lap numbers, than put them directly into the lap tag. Also the split times. e.g.:

There should only be one result tag, so the result and finish should be merged to avoid duplicated informations.

Quote from Brilwing :

Namespaces only make sense if other kind of data is also included in the XML file, and that is not the cause with the stats file format. If you want a valid XML file so that the parser has no problems, than a XML-Schema is the right way.
So we need no namespaces here, it only make things complicated.

As i see it, namespaces do not complicate things, they create an extensible format where you can put other kinds of data in the file. Since i want to be able to add extra data for rendering live progress, using namespaces makes alot of sense.

Surely it is possible to validate an extracted node / namespace instead of the entire file.

Quote from Brilwing :

As I wrote earlier in this thread I don't like abbreviations. You sometimes use full names in your example, and sometimes use abbreviations.
So always use full names like username instead of uname, or position instead of p.

I agree.

Quote from Brilwing :

Also the time should not be formated. XML is mostly read by programs so a unnecessary parsing could be avoided.

The time is actually not formatted, i've dumped it straight from LFS as m.s.h.t

Quote from Brilwing :

If the flag tags have lap numbers, than put them directly into the lap tag. Also the split times. e.g.:


<lap count="23" position="3" time="1429400">
<split number="1" time="0282100"/>
<split number="2" time="1059700"/>
<flag colour="blue"/>
<flag colour="blue"/>
</lap>


There should only be one result tag, so the result and finish should be merged to avoid duplicated informations.

I agree.

Is this format meant to be human readily human readable?

I really don't think it's that important myself, however ... I would no go about using things that no one has ever heard of in places that people should know. I would use uname, and pname, as they are well defined (In my view). I think that the format should read like an XML file that takes ques from insim packets. One readme.txt file to rule them all! I also think that namespacing the stats is a MUST. It should be eXtendable as we are doing it in a Markup Language. So some parsers can't read that ... well then, don't use them. We are here to make an XML file that validates to it's own format, and that format just so happens to be about Live For Speed stats, weather or not it's live or from a replay. You kill so many different birds with one stone like this.


Confirmation flags definition
-----------------------------
MENTIONED 1
CONFIRMED 2
PENALTY_DT 4
PENALTY_SG 8
PENALTY_30 16
PENALTY_45 32
DID_NOT_PIT 64

Quote from filur :

Since i want to be able to add extra data for rendering live progress, using namespaces makes alot of sense.

Ok, than namespaces are fine

Quote from Dygear :

I think that the format should read like an XML file that takes ques from insim packets.

Hmm, first I also thought that is should be analog to insim, but now I don't know if it is the right direction. The goal of the common stats format is that different tools can use the same input format. Why not different racing sims. I mean that the naming or values like penalty should not be lfs specific. e.g.:

What do you think?

You know what, I'm not sure what I think about that right now. I see where you are coming from, and I'm pretty much coming from the same place as SimFIA runs things for LFS and soon rFactor. It would be nice to have a universal format, but thats out of the scope of this I would have to say. I do know where your going tho, and I do like it. The whole name space thing works well in a situation like this.

lsf - Live For Speed Stats Format.
rsf - rFactor Stats Format.

Quote from Brilwing :

Why not different racing sims.

Dangerous ground. Make something work for 1 platform and actually do it well, before you attempt more.

Quote from the_angry_angel :

Dangerous ground. Make something work for 1 platform and actually do it well, before you attempt more.

Sure, we should concentrate on LFS for now and the information that we can gather with InSim, but we can also keep an open mind.

If we (only) want a XML format of the InSim Events, than make everything like it is discribed in the InSim.txt. e.g.

is than

I don't want that. I want a clean format that one should be able to use without InSim knowledge.

I´m not for most of the last examples because they all have so many useless data. For example the penalty type in every lap entry. How do you get a penalty that such thing is needed.
Also you have pit, flag, take over... Where do you want to go with this.
Every example has only parts of all availible information in it and I think most times you don´t think enough forward.
Maybe in a common format there is no space for speed because its also not the easiest thing to implement. But you can´t take out pit, tyres, flag and so on...
So why do we don´t use my way to use a list of all those infos? In my opinion thats the best way. Easy to implement and the easiest way to parse. I don´t understand why you try hard to get something else.

Quote from CLRS530 :

I´m not for most of the last examples because they all have so many useless data. For example the penalty type in every lap entry. How do you get a penalty that such thing is needed.
Also you have pit, flag, take over... Where do you want to go with this.

What useless data? We do not put a penalty tag into the lap tag when no penalty event happen. Only when a penalty, takeover, flag occurs, than a tag is added to the proper lap when the event occurs.

Quote from CLRS530 :

Maybe in a common format there is no space for speed because its also not the easiest thing to implement. But you can´t take out pit, tyres, flag and so on...

As I suggested earlier in the thread, we should put mendatory info in the format, but the speed should be optional. But we should only put infos in the file that are useful. I only think that the top speed is one useful information. As I remember there were more things in filurs example is not available anymore, so I cannot give an example whats useless.

Quote from CLRS530 :

So why do we don´t use my way to use a list of all those infos? In my opinion thats the best way. Easy to implement and the easiest way to parse. I don´t understand why you try hard to get something else.

Maybe not every body is happy with your format.

Latest revision of my stuff,

Fri_13_Apr_2007_17_05_23_+0200.xml

Fri_13_Apr_2007_17_05_23_+0200.png

Quote from Brilwing :

What useless data? We do not put a penalty tag into the lap tag when no penalty event happen. Only when a penalty, takeover, flag occurs, than a tag is added to the proper lap when the event occurs.

I mean an example of Dygear, he put the penalty tag in every lap "<lap ... penalty="0">"
Putting a tag <pit> behind <lap> if its in the right lap is this really a valid xml structure?
One thing I see as valid would be

But maybe I only have another thinking of it.

Quote from Brilwing :

Maybe not every body is happy with your format

Don´t lay words in my fingers I never wrote.
I wrote to use the idea of those lists instead of put every event into the lap list wich comes strange to me.
Also you can easy write "attacking words" but I discuss what I like and I argument what I don´t like on other formats.
You could come with arguments but thats no way.

Quote from filur :

Latest revision of my stuff

Yes that at least is also for me the best from all ideas.
I think we need a flag in the lsf tag wich shows if speed is in it and if there are pit information.
The best idea is to split the new packet information in two bits. One bit for the new information and one additional for pit and take over... because on an old replay you get flag and so on, but no pit events.
Also the time should be changeble to hundreds of seconds. That was a request on my file and I implemented it.

Thats a nice basic think,but there are no new packet information in and we have continue working on bring it together to a result.
For me it would be nice to have the speed for spilts too, but if I´m the only one who do this it´s not good for you I know.
But on the other hand I couldn´t be compatible with my main output.

So splits times would be SPX and split speed for that split would be what SDX? I would have to say then when the cross the start finish straight that it would be SDL, and for the fastest speed overall on that lap SED (If we should include it).

Also, I do think that leaving the time in the MHTS format would be the best for us all. 3000 for 30.00 or 0:30.00 or 00:30.00 or 0:00:30.00 (Ya see my point).

Quote from CLRS530 :

Also the time should be changeble to hundreds of seconds.

Using 1/100th's of a second is a bit of a bad idea since LFS might, at some point, start filling in the thousands.

I've found "m.s.h.t" extremely simple to work with.