Comments on: An XML Design Dilemma

By: Trond Wingård

Trond Wingård — Wed, 12 Oct 2005 07:43:06 +0000

For me, as a non-XML-savvy person, I think the second XML is indeed better. And it has to do with readability. But why?

I have two slightly different explanations for why the readability is better in the second XML. One, it gives me a context for the actions (”What are these? Oh, they’re available actions. OK.”). Two, it introduces a mental concept (available actions) which quickly leads me to investigate if this is a complete list or if there should be more actions available - it sort of focuses my thinking. (Which is only good if the concept introduced is good - which, in this case, it is.)

By: Jeff Grigg

Jeff Grigg — Sat, 08 Oct 2005 23:39:16 +0000

P.S. (And this blog software removed all the XML elements too. Bother!!! ;-)

By: Jeff Grigg

Jeff Grigg — Sat, 08 Oct 2005 23:37:30 +0000

> Re: Gilles comment at September 26th, 2005 at 2:10 am: > "Here is my take on this question : from a computer point of view, > both designs are equal. In both cases, you can return the list of > actions with a simple XPATH expression."

They're not equal, from a computer's perspective, if you drop the assumption that you'll use XPATH to find them, and the assumption that there will never be elements at a deeper level. For example, in the future, an action could describe further actions that could be taken after this one. Those nested actions would be enabled (or excluded) by this one.

The first XML mixes elements of two different types: Attributes (identifier, type, description) and the elements of a set or array of actions. But the "set or array" is missing from the XML. Grouping the elements in an element simplifies the view from the element to its children. Consider a tree view of the XML, where you can expand or contract each node. In IE, for example, I can display this data like this:

| - | 1234 | ForkReached | There is a fork in this path. Which way do you want to go? | ... | ... | ... |


1234
ForkReached
There is a fork in this path. Which way do you want to go?
+

And then, *IF I'm interested in the detailed list of actions, I can chose to look at them:

| - | 1234 | ForkReached

There is a fork in this path. Which way do you want to go?
...
...
...

That's why it's better.

(And it's also worse... Because Word messed with the quotes and ellipses in the second XML. ;-)

By: Peter Williams

Peter Williams — Thu, 06 Oct 2005 20:30:25 +0000

Tim, you are correct that the second form is only easy to read because the elements are ordered in a particular way. However, XML is not unordered. There is a defined order to any document (document order) and in with XML scheme you can, and in most cases do, define a required order to the elements (a 'sequence' in XML schema requires that element occur in the specified order for the document to be valid). Therefore, the schema for the documents could easily specify that the action elements could only occur at the end of the document.

On the other hand, you, I and, I think, most other people tend to think of XML documents as unordered (actually, we tend to treat the orderedness as a bug to be ignored/worked around) and, as far as I can tell, very few people actually validate their documents so depending on the order required by the schema is pretty much just folly. Unless, of course, all the software involved is controlled by the same team, which in this case it is.

Still I think the readability argument is the best one. The second from is more readable and is more resistant to obfuscation.

By: Tim Rapp

Tim Rapp — Thu, 06 Oct 2005 20:03:23 +0000

When you parse those two xml snippets, the first could have actions interspersed with other event elements (since XML is unordered); the second would have all of the actions grouped together. It’s all the same to a machine (give or take), but much easier for a human to deal with.

By: Bernard Notarianni

Bernard Notarianni — Sun, 02 Oct 2005 09:20:17 +0000

The frontier

My favorite recurring big theory is that information management systems are very particular animals compared to scientific or industrial systems. Their main purpose is to automate into a machine some processes which are by nature human process....

By: Peter Williams

Peter Williams — Tue, 27 Sep 2005 18:38:49 +0000

Julien, interesting approach. Unfortunately, in this case I think that neither design would ever reach its limits. It is quite unlikely that any refactoring will ever be required and the volume of messages will be measured in messages/week rather than per second.

By: Peter Williams

Peter Williams — Tue, 27 Sep 2005 18:26:32 +0000

Gilles, maybe the human readability is the best argument. I think that argument, while correct, is a bit tenuous. It is not really difficult to read the first form. I guess you could say that since the cost of the extra element is negligible, even a marginal improvement in readability warrants the change, but it feels a bit contrived to me.

By: Julien Cabot

Julien Cabot — Mon, 26 Sep 2005 15:07:53 +0000

To resolve quickly such dilemma, I apply a “distance to limit balance” principle.
I don’t look for why a solution is better than another one, but I try to estimate each solution limit as a design limit over there it will not work and I reject the solution where the limit is the more probable (the closest to my current context as a system of constraints).

For example :
Limit for the 1st solution : grouping actions involves a structure refactoring
Limit for the 2nd solution : extra characters (~40o) cost is 1 for 1000 messages/second for a SLA of 100 message/second.

The distance to limit of the 1st solution seems to be closer to you than the second one. Hence, the second solution seems to be the best at the current time, because the second solution push far the limit. People like to be free of…constraints, isn’t it?

By: Gilles

Gilles — Mon, 26 Sep 2005 08:10:38 +0000

Here is my take on this question : from a computer point of view, both designs are equal. In both cases, you can return the list of actions with a simple XPATH expression.

I don't believe the second design allows for better extension because you don't know what the future will be like. So you don't know for sure that your design will accomodate for it. On my defense, I believe in just-in-time design (= design for the present moment).

To me, the second design looks better because it is more human readable.