giwo wrote:I recall in the past you wanted to do much the same thing...
yes, the fundemental issue hasn't gone away.
Lets examine the objective, not the implementation.
1. Data definitions/formats should be self defining
2. Data syntax should be consistent, and parsable without knowledge of the data.
What those say, in a nutshell, is :
1. I should not have to know the file name, or some outside source of information, to understand what type of data I am dealing with. It should be identified in the data.
2. I should not have to be aware of the data content, to be able to parse it (like I can parse any xml file, without understanding the data within it.
Ok, now apply those two objectives to the DFNs. Clearly, since some times you have tags like : "tag = value " , "tag = value value", "tag = value,value" , and "tag = value with a space" , one can not parse the data without knowing something about it. so it fails item 2 at least.
Now, think about the different data files scatter around. Unless you know the directory, and sometimes the file name, you don't know what type of data the sections are describing. It would appear an attempt was made to get around that, with items like : [MENU ###], [ITEM ###], and [CREATURES ###} scattered in some of the files, mostly menu related ones. So it doesn't meet critiera #1 either.
Those two points are my fundemental issue with the format. I have other "issues" with it, but they are not nearly to the scale as these two. Imagin if you had to have a custom xml parser (just a parser mind you), to be able to parse any XML file, and the location of that file (or name) had some bearing on how you parse it. It would become a maintenance nightmare.
So I am open to any modifiations that tackle these two issues.
In that scenario, I believe one of the goals was to return to a format more like
[SECTION ITEM ####]
{
}
vs the current
[####]
{
}
would that still be required?
no, I am open to any suggestions that address the above issues. The reason I preferred the SECTIONKEY TYPE ID approach was it clearly indicated a way to meet the above item # 1, and it didn't seem to have any drawbacks over the [ ] approach. In otherwords, what did the [] gain? I could easily extraplate what the SECTION ITEM ### provided, with no loss. But there appears to be a lot of emotion in the [], so that approach is fine, if an extenstion is found that provides item # 1 in the confines of [].
As for a standardized delimiter, while the space has proved effective in the past, I have no problem with finding a good unique separator to put in between values. The only major issue is forcing all the scripts to be updated once again.
Well, it isn't effective given item # 2. For one can't tell when to parse it, without knowldege of the data being parsed. If knowledge of the data is required, then almost any method is effective.
As for requireing an update once again, yes it will. In my defense I pointed these issues out, even before .9x switched to dfn (first release supported the other format). I assume the dev team decided it wasn't desirable, or had other reasons (again, it seemed to have a lot of emotions tied up in it). But clearly, it doesn't encourage developement from outside tools, if something as parsing has to be custom built. Perhaps the hope one can have this time is there is a stated list of objectives that is to be accomplished by the format, and one can see how it is met. truthfully, I have yet to undestand what the DFN format provided over the other format (for one didn't have to use numbers for id's there either, from a "format" perspective. I would offer, that there might be other minor items that should be considered if one wants to prevent doing it "yet another time".
As for things like [ITEM ####] I'm suprised that script even still functions, as I'm pretty sure we lookup our item entries to be an exact match to whatever is in between those brackets.
Well, those are mostly in the Menu items. But yes, perusing throught the 9070 sections defined in the data/ directory (all files with a dfn extentsion), there are at least the ones I mentioned above.