Category Archives: StackOverflow

.NET and XML: Mortal Enemies

In the past, I’ve had my issues when dealing with the compatibility between C# and XML, so much so that I’ve been inspired to write prose. At this point, I feel that it’s my duty for posterity to document the various instances where Microsoft drops the proverbial XML ball:

  1. As stated before, DTD validation of XML files (with the C# XmlReader) is broken. And when I say broken, I mean that it performs as well as a thirty-year-old VCR pulled from the ocean and then placed in a vat of hydrochloric acid. Now plug that VCR in. You’re going to get the same results.
  2. If you’re hoping to create a XSD from available XML or classes with the Visual Studio Tool (i.e., XSDT), good luck. For one, it doesn’t allow you to specify any complex rules. Also, if you’re generating a XSD schema from classes, you should know that it doesn’t work with Nullable types or any Dictionary properties, since they couldn’t budget it into their schedule.
  3. “Hey, I have a container that’s set to null. So I’ll tell C# not to mention that tag at all upon serialization, since it’s just wasted space and since I might not want that tag visible in certain cases.” It is possible…but under specific circumstances. If you plan on serializing your class as is and if you plan on not using any C# attributes on your properties, maybe. Otherwise? Nope. C# says “No soup for you!”
  4. If you want to serialize an array of strings, you get a free bonus upon serialization: all of the tags will be prefixed with a namespace (i.e., the namespace for array serialization). If you don’t want that ugly prefix, just create a wrapper container for a string array. Now do this for every literal type you can think of.
  5. Let’s say that you have a XML doc with a string that is a HTTP link. You now want to parse that XML and read that value. Of course, if that link contains a query string, all of those ampersands are already converted into instances of “&“, in order to be compatible with XML standards. “But I want my data to be read incorrectly!” Well, you’re just in luck, friend! Because when you use XmlDocument.Load() to deserialize that XML, that query string will contain “amp;” and not “&“, essentially turning the link into garbage. Huzzah!

These are only a few instances, but there’s more. (Don’t even get me started on deserializing payloads from a ASP.NET web service.) If anyone out there has their own experiences to add, I’d love to hear them.

Quick Tangent: An Open Standard for Indoor Navigation

“Since when did this blog become solely about indoor navigation? I thought that this thing was supposed to be about metadata?” Well…I can’t argue with you. I need to get back into that at some point.

In any case, after sampling different platforms for indoor navigation, I’ve come to notice something: there is no open source standard for indoor navigation yet. Of course, there is much discussion about indoor navigation within the gaming industry, especially within the community for Google’s Project Tango…but there isn’t as much talk when it comes to API standards. Considering that open source standards seem to be falling from the sky in the last few years (for cloud computing, for automobiles, etc.), it seems fitting that one of the bigger players (like Indoor Atlas or Estimote) should take this opportunity to lead the way with an open standard. As IoT invades our lives, indoor navigation will probably become more prevalent, and more development standards would be beneficial to the industry. (Of course, these Northern Europeans are probably too busy slugging it out, since that’s part of the travails of being a startup company.) I suppose another unmentioned company could also take this lead, but I’ve found that many are not as developer-friendly as Indoor Atlas and Estimote; most require any interested parties to fill out an application before even allowing access to their documentation.

Now, it wouldn’t have to be an all-encompassing standard, but it should probably take into account each of the strengths in the current set of available platforms. In addition to the practice of emulating Apple’s Location Manager (which they all seem to do in their iOS SDKs), an open standard could include interface methods for functionality like:

  • The ability to overlay the indoor navigation map over an actual world map (which is offered by Indoor Atlas).
  • The ability to generate a map of the indoor space dynamically (which is offered by Estimote).
  • The ability to raise a signal (email, text, etc.) when someone enters the navigable area (which is offered by both Indoor Atlas and Estimote).
  • The ability to generate an account with the vendor’s services programmatically (which I could see as being helpful to developers who want to incorporate these services into their own products).

Maybe I’ll create a sample and upload it to Github in the near future, as a more verbose example.

On a side note to this new standard, we can leave out some of those confusing and misspelled messages that are generated by Apple’s Location Manager. Who comes up with these things?

Further Experiments with Bluetooth

So, while I’m still waiting for the Android port to Raspberry Pi, I did a little more homework, making some notes about calculations that would eventually be needed for my project. More importantly, I started to reconsider the whole idea of having a platform-dependent solution to the sensor for the Haunted House game. I mean, there has to be something out there, right? Something cross-platform like JavaScript…hey, wait, Google has the Bluetooth Chrome API! That’s perfect!

Excited yet again, I started to look over the documentation, and I started to play with the samples. So far, so good! Using the API, I could detect my smartphone when the Bluetooth was enabled…and I didn’t even need to pair it! Now I just needed to read the RSSI value on the Device class, and using the calculations, I could create a proper sensor capable of estimating the distance to nearby Bluetooth devices. “Wow, this is going to be so great!” But then I noticed that there was no value being populated for that property. Hmmm…oh well…maybe I wasn’t doing something right. So, I poked around on the Chromium site, and it revealed to me…oh no…

https://bugs.chromium.org/p/chromium/issues/detail?id=552268

So, the developers of the API are debating how to properly set the RSSI value for the signal, since there are nuances when it comes to the detection of the device. They haven’t come to a consensus yet…so, for now, the property remains unpopulated. Which brings me back to square one yet again.

I’m getting used to the disappointment…

…but the darkest hour is just before the dawn! And that was confirmed when I found Estimote while preparing to jump off a cliff. My manic ride is at an apex once again, and I’m looking forward to performing a few experiments in the future.