Archive for the 'Design' Category
How to NOT Create an XML Schema
April 10th, 2008

During the life of any developer that does any sort of work these days, the chances that they are going to have to use some form of XML are pretty much 100%. This absolutely not a bad thing. XML has transformed the way that we look and use data.

Before XML, many computerized business systems communicated through regular-timed batch files using Electronic Data Interchange (EDI). The format of EDI Files were usually some sort of delimited text file (fixed-width txt’s, csv, etc.). On a lower level, these files aren’t really any different or any less efficient than XML (in fact, using them is probably more efficient from a CPU-Cycles and file-size standpoint. You don’t have to parse an EDI file, and there’s no tag based overhead to add to the filesize) However, the big reason that XML took off was that it was readable by both humans and computers. The tags read almost like a story. Anyone who’s google’d XML has probably come up on the classic w3c schools example:

<note>
  <to>Tove</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Don't forget me this weekend!</body>
</note>

This is beautiful. (OK, it’s a very simple example… maybe beautiful is a bit too much but you get the point) It’s a standard data format for a note that a developer can open up, inspect, easily edit, easily create new ones, and the best part is machines can interpret them as well.

Let’s take a look at some kick ass implementations of XML.

HTML

This is probably the first ever implementation of XML, and may even be considered the father of. HTML was already rampant throughout the world wide web before XML was even coined a term. While it’s not truly XML (tags aren’t required to match or end, but they basically have to otherwise browsers have to interpret what they think you really meant) it shares the same format of a tag based document layout. You have your <HTML> document, and inside that you have your <HEAD> which contains <meta>-data about the document such as the <title>. And of course, you have your <BODY> which contains the actual content.

SOAP

SOAP is the de-facto standard for webservices. A web service being, of course, some sort of HTTP Request that accepts input and returns machine-readable output. Part of SOAP is the WSDL, which uses XML to define the input and output paramaters that a webservice exposes.

OK, Now let’s look at my favorite example of an organization that entirely missed the point of XML.

NEMSIS

If you’re a developer working in the emergency medicine field, chances are you’ve probably heard of NEMSIS. It’s the standard for sharing Emergency Medical Systems (EMS) Data. Here, take a look for yourself at an example NEMSIS document:

<?xml version="1.0" encoding="UTF-8"?>
<EMSDemographicDataSet xmlns="http://www.nemsis.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nemsis.org http://www.nemsis.org/media/XSD/EMSDemographicDataSet.xsd">
	<D01 Status="A" Date="1967-08-13">
		<D01_01>String</D01_01>
		<D01_02>String</D01_02>
		<D01_03 Status="A" Date="1967-08-13">-5</D01_03>
		<D01_04 Status="A" Date="1967-08-13">12345</D01_04>

		<D01_05>5610</D01_05>
		<D01_06 Status="A" Date="1967-08-13">-5</D01_06>
		<D01_06 Status="A" Date="1967-08-13">-5</D01_06>
		<D01_07>String</D01_07>
		<D01_08>5810</D01_08>
		<D01_09>5870</D01_09>

		<D01_10_0>
			<D01_10>2006</D01_10>
			<D01_12>2</D01_12>
			<D01_13>2</D01_13>
			<D01_14>2</D01_14>
			<D01_15>2</D01_15>

			<D01_16>2</D01_16>
			<D01_17>2</D01_17>
			<D01_18>2</D01_18>
		</D01_10_0>
		<D01_11 Status="A" Date="1967-08-13">-5</D01_11>
		<D01_11 Status="A" Date="1967-08-13">-5</D01_11>

		<D01_19>5900</D01_19>
		<D01_20>0</D01_20>
		<D01_21>-5</D01_21>
	</D01>
	<D02 Status="A" Date="1967-08-13">
		<D02_01_0>
			<D02_01>String</D02_01>

			<D02_03>-5</D02_03>
			<D02_02>-5</D02_02>
		</D02_01_0>
		<D02_04_0>
			<D02_04>-5</D02_04>
			<D02_05>-5</D02_05>
			<D02_06>-5</D02_06>

			<D02_07>String</D02_07>
		</D02_04_0>
		<D02_08>-5</D02_08>
		<D02_09>-5</D02_09>
		<D02_10>-5</D02_10>
		<D02_11>-5</D02_11>

	</D02>
</EMSDemographicDataSet>

If you can understand what kind of data you’re looking at without referencing the 450+ page “data dictionary” (and that’s just the start, there’s also a 2600 line excel spreadsheet for good measure), I will give you $1 (I’m cheap).

Please, don’t get me wrong. This is a fantastic initiative by the NEMSIS group because of all industries in America, the medical industry is by far the most behind on the technology curve. In fact, the company I work for is NEMSIS Gold compliant and we openly embrace this standard, for the obvious benefits it has to openness and standardization of data.

It’s great that NEMSIS’s goals are working towards open standards for system communications, but for crying out loud, did the team that created the schema even read the World Wide Web Consortium’s goals on XML?

The design goals for XML are:

  1. XML shall be straightforwardly usable over the Internet.
  2. XML shall support a wide variety of applications.
  3. XML shall be compatible with SGML.
  4. It shall be easy to write programs which process XML documents.
  5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
  6. XML documents should be human-legible and reasonably clear.
  7. The XML design should be prepared quickly.
  8. The design of XML shall be formal and concise.
  9. XML documents shall be easy to create.
  10. Terseness in XML markup is of minimal importance.

To me, that’s a pretty big point they missed.

Posted in Design, Rant by ken.sykora
1 Comment
Throwing exceptions in cfscript
June 18th, 2007

So… apparently cfscript doesn’t have any sort of implementation for inside tags. This seemed rather silly to me, considering it supports /

try { i = 3/0; }
catch (any excpt) {
//do something… just don’t throw() anything.
}

After some quick googling, I discovered that good ‘ol Ray Camden wrote a UDF for the throw(). He also has a blog post about a function rethrow().

Thanks, Ray!

Posted in Implementation by ken.sykora
No Comments
Why Code Visibility is Important
June 4th, 2007

I read an interesting blog post this week on Submerged (the official Subversion blog) which had an interesting take on why open-source development models work. The blunt of it came down to the fact that people write better code when it is exposed and reviewable by others.

For example, visibility seems an obvious approach to better quality that should be enabled by our processes. First, one is going to be more cautious in their work knowing that it can potentially be seen by the broader project team. It is a strong deterrent to shortcutting the coding standards that the project (or the enterprise) has identified. Second, the code benefits by having more eyes reviewing the changes, which means a higher probability of issues being identified earlier in the lifecycle at a lower cost to their enterprise. I realize some people are reticent to having their work “exposed”, but that shouldn’t be an inhibitor to doing the right thing. Most of the people that you really want doing the work will welcome the chance to share their “brilliance” at a more detailed level. This visibility is achieved to some extent by general read access, but also by posting deltas to a mailing list and its associated archive. Visibility can also be enhanced through an association of the delta with a change request

Great stuff coming from this blog. I can’t agree more with what the author says. It’s one thing to write code that doesn’t work, it’s another thing to write code that works but is terrible in design. That’s what prototyping, tracer-bullets, and branches are for. Having your code visible to the rest of the world will let anyone see your real skill as a developer

Posted in Design by ken.sykora
No Comments