Re: XML Interchange format
 

If there is one thing I cannot stand... well, if there is one thing I cannot stand about programming, it is Python.

SQLite, Postgres, MySQL, relational databases in general are for storing data. They are not for transferring it. Even when backing up relational databases, do you copy the binary files? No, you export the SQL statements that can re-create the database from scratch as a backup. SQLite is not a data format, it is a database. There is a distinct difference.

Absolutely not a problem :)
Yes, XML has weaknesses. Relational data also has weaknesses. There is no one killer data format, and you have to choose what makes sense and understand it won't always be the correct choice. Again, for sharing data, XML is well suited because you can put comments in it, it is human readable. I can open it up in a web browser and inspect the data - huge plus, at least one person has already done so. Namespaces are a plus, it is extendable, and elements are inherited from other elements, that is to say there is an ancestry. It is made very clear that teams can belong to seasons, events, and matches, scores can belong to a team or a match, and so on. Such flexibility is hard with relational data, which is fairly strict. Shipping around data in a relational format confines DBAs to a straitjacket, I am re-working my own database right now (have been for two weeks on and off, and there isn't a real end in sight) because I described alliances, scores, and events in a bad way, and am really paying for it with my time.

Re: XML Interchange format
 

I am wondering why you are bashing python, as it is an excellent language for scripting, which is what this is all about. Do you really want to write your database scripts in C? I dont think so. I was speaking about writing a TurboGears or Django app which is fully python css and html (none of the php mumbojumbo already went through that stage of my life). One of the cool things about these apps is the model.py file which defines your database very simply and in an Easy-To-Read way.

If you read what I wrote I was not wanting to ship a SQLite file around. But have a standard model that can be created that people can put on there computer, and have the scripts to Take Your XML Format and place it in a database, and export the data base to your XML format.

It seems to me this could be powerful. People can write scripts on the database in what ever they want (python makes this easy), and they can see the data in the XML format if they want during transition.

As for XML as a database format... come on. Even xindice on there front page says it does not serve as a general database. I have played the XML database game in past years and know where it leads. I still use XML for data transmission all the time.

Re: XML Interchange format
 

Nobody is saying you can't have a SQLite/Python parser, but ultimately not everybody is going to use the same language framework. Once this format is documented and stable you can write you Python scripts , I can write my .net apps, and some guy over there can write his Ruby scripts or Java apps or PHP site.

I don't think anyone is intending to use this format for long term storage, not that somebody won't ;), but for inter-team or even intra-team data transportation this could be a very useful format.

That problem with that statement is that not everyone will agree on the exact data for each match, event, or even season. I think the way this should be approached is that the format will provide all of the functionality for 95% of the people using it, but the data from the 5% who want other data included should still be usable so long as they don't leave out any required fields.

You could still include a format version, but it would only be the base format (i.e. not specifying the 5% usages).

If you don't allow this people will either branch the format and create many similar, but incompatible formats, or the format will become a mess of with 95% of the spec being for the 5% use cases (insert generic Windows bloat joke here).

Re: XML Interchange format
 

Or API calls... :)

Re: XML Interchange format
 

I'm not very savvy in this field, but this whole thing seems interesting. I'm currently working on creating a regional intraweb that teams can connect to.
At first I was going to implement one of the other solutions already floating around, but if this'll be ready before Week 1, I'll be happy in trying it out.

Of course, I'll need help integrating it into a CMS/Website. Keep up the good work! :)

Re: XML Interchange format
 

It is only a data format, there is really nothing to program, maybe proof of concept implementations to test what features will be needed and such. I am trying to work this into my own scouting program/archive. People can start implementing it right away. (A few more tiny changes may occur before it is "stable" but that shouldn't stop anything)

Why not create a new thread about this intraweb? Also, I can't imagine it will be very accessable if Wi-Fi won't be allowed in the pits.

Re: XML Interchange format
 

I know, I've been reading the Wi-Fi threads. I truly hope FIRST doesn't cripple us in that area.

Well, like I said, I don't know what all this thing is about. :D Maybe if you can help me understand how this works, I might be able to write up a simple interface to use for my site.

Re: XML Interchange format
 

I'll break this down such that anyone could understand.

First off, it is an interchange format, used for taking data that one person logs and moving it into another place that doesn't have the data. To read the data, you have to have an XML parser and that can parse the data and then programmatically read it from a tree-like structure (The DOM, an Ent I like to call it ;) and do what you want with it (insert it into a relational database, etc). To create the data, you can reverse the process, create nodes in the DOM and ask the library to create XML. At minimum you have to be able to write UTF-8 characters and serialize the &">< characters to their XML entities, &amp;&quot;&gt;&lt; respectively, then print the XML tags and serialized names/values. Of course, the data has to be in the structure defined in the specification document in my first post in the thread, otherwise it wouldn't be exchangeable.

Re: XML Interchange format
 

Erm, thanks? :) Still a bit foreign to me, but now I think I understand the basic concept. I'll work with it for a bit. It'll keep my mind off the depressing fact that I'll be teamless this season.

Re: XML Interchange format
 

Ok, still lost, and probably going to need somebody to walk me through getting this to work on a PHP site.

Re: XML Interchange format
 

You are going to want to look at SimpleXML, it is the easiest way to access XML data imo. Be careful when accessing text nodes, you have to convert the object to a string with (string), e.g. (string)$root->node;

Accessing a season of data would be pretty simple, foreach($root->team as $team) will take you through all the teams in a season or event.

I am working on a scouting program (a better version, I really hate the way data is stored and edited in the last version I have posted) that will be making more use of it. If you want to chat about it, see my footer for more info.