Eight of the companies planning to run US databases of White Space have published the XML schema, and polling protocol, they intend to use to keep their data synchronised. The two documents, Database Interoperability Specification (65-page PDF/1.2MB, very XMLy) and the Channel Calculation Guideline (19-page PDF/965kb, very …
So you're designing a system that needs to use low bandwidth...
... but you've decided to use XML to transfer data.
Hello? Whats wrong with this picture...
Sure , you can compress it but thats rather like buying a square ball then putting rollers on it so it can move more easily.
Doesn't anyone these days understand binary formats or does everything had to be lowest common denominator so idiot coders can cope by using off the shelf bloatware libraries to parse it?
Re: So you're designing a system that needs to use low bandwidth
Er... compressed files are binary. Compressing XML files in particular, which have easily identified tokens to compress, gets you a very small file.
And just which compression libraries are "bloatware"? Re-inventing wheels is all well and good if you think you can do better -- go ahead.
"Er... compressed files are binary. "
Yeeees, well done. But they're not a data transmission binary format are they which anyone with half a working braincell would have understood that's what I was talking about.
"Compressing XML files in particular, which have easily identified tokens to compress, gets you a very small file"
A specially designed binary format would be even smaller plus it wouldn't require to be topped with a header so you know how long its going to be unless you're expecting the low level network code to understand the compression format?
"Re-inventing wheels is all well and good if you think you can do better"
Funnily enough XML was a re-invention of the wheel. A bad one. And if you want a better data format then have a look at JSON. Not only is it a damn site more human readable but it takes up less space.
Re: @John Gamble
"But they're not a data transmission binary format are they which anyone with half a working braincell would have understood that's what I was talking about."
Sadly, no. A: I did know what you were talking about. B: You were wrong.
Coming up with a specialized transmission format, which does not solve an existing problem any better than existing standards would be a bad decision. Your knee-jerk dislike of XML is exactly the sort of thing that gave us the abomination YAML.
(I agree that JSON would be a better format, but again, that's irrelevant to the point that you thought you were making).
It sounds a lot like...
... "DNS for White Space."
It would be cool, though, if they would implement it in a way that was actually similar to (secured) DNS, so that the requesting/querying device didn't need to go directly to a top-tier "root server" to get a list of available White Space channels (frequency ranges).
The additional redundancy created by additional "White Space Spectrum Availability Protocol" (I just made that up) caching servers would go a long way toward ensuring that your node doesn't suddenly find itself lost in the woods without a map, so to speak, if one of the spectrum availability list providers falls over.
The caching servers would be made read-only (from a client perspective, since updates can ONLY be provided by one of the registered White Space database maintenance companies) and multi-homed (i.e., it gets data from a primary provider, then falls back to a list of secondaries if the primary isn't available).
A new record type would be created and implemented in the real DNS protocol that would provide information regarding the address of the nearest WSSAP caching server. A WSSAP-compliant access point would then query a local DNS server, and ask it for the DNS server's preferred WSSAP caching server. The info would be passed by the DNS server back to the device, which would then query the WSSAP server(s) listed in the DNS reply.
"Sadly, no. A: I did know what you were talking about. B: You were wrong."
Well I've been involved in data transmission projects for a number of stock exchanges (LSE, Madrid, Norex) so excuse me if I pull rank on this - I think I have a vague clue as to what works well and what doesn't over a network.
"Coming up with a specialized transmission format, which does not solve an existing problem any better than existing standards"
Newsflash - XML is not a transmission format. Its a data storage format. It was never designed to be a base format to be sent over the wire and using it as one is just lazy and ignorant, not to mention inefficient. As for YAML , its not perfect but I'd take that any day over the mess that is XML which was designed by people who had no clue as to the different between a markup language and a data storage format and apparently thought SGML and HTML were the bees knees.