tags:

views:

332

answers:

2

Based on what I've seen on Oslo, declarative XML will have a key role. Can I expect to be mucking around a lot of designer generated XML to create real world applications? Just know I haven't researched this. I would just appreaciate your perspective if you have examined the subject.

Some background...

Whenever I dig just under the skin of any XML backed declarative technology (such as Silverlight and WPF, ASP.NET, or MSBuild) it seems I end up editing a lot of raw XML text. The designers are seldom expressive enough for my needs.

One one hand I can't really see better compromise between human and machine readability, and to be fair, the XML editing experience gets better with each incarnation.

On the other hand I havn't found XML ideal for some of its usages. Especially when it comes to expressing logic, and for refactoring and testability. May it be the designers are too weak, or the XML too expressive, or I, too grumpy and spoiled by objects and methods.

+3  A: 

I tend to make for a somewhat dubious champion of XML. Despite the fact that I use it daily, and that XML-based webservices have been a large part of my career (and the basis for the book I wrote), I think it is widely over-used. I tend to belong to the school-of-thought that believes you should have many tools in your toolbox, and you should use the best tool for the job. There are a lot of things for which XML is an excellent solution. But there are plenty of things for which it isn't, and some for which it's probably a terrible choice.

Just as some people are zealous in their criticism and avoidance of XML, some people are just as zealous (or more so) in their praise and use of it. In the cases you refer to casually above, you're talking about web-based technologies for the most part. In these cases, you generally already have an XML parser and/or DOM manipulator already available to you, so there is no harm in making use of it. You haven't added to the complexity, because it was already there. Flash & AIR make heavy use of XML for functionality, but they are targeted to an environment where parsing XML-ish markup (if not XML itself, then HTML or XHTML) is a core part of every application. For these technologies, introducing a different sort of data-expression language would be what adds complexity. Using XML makes perfect sense.

Here's an example... the language in question here is Perl because that's what I use primarily, but the Perl-aspect of it is not relevant to the point: I've been working on an extension of an existing module that dumps deep data structures. Useful for tons of things-- serialization, portability across platforms, etc. Also a popular tool for debugging. My reason for wanting to extend it is that truly large and complex structures (such as those produced by ORM or MOP frameworks) can get pretty hairy. So my first thought was to just make an extension that let me convert the data to HTML in a way I could exercise some control over. Then I thought that it would be nifty if I could create diagrams showing the various elements and which is linked to which, etc. Then it occurred to me that if I chose a reasonable neutral format, I should be able to derive both of those fairly easily.

That format? XML. Why would it be necessarily better than the native Perl serialization structure in this case, or better than using a different interim representation (such as YAML or JSON)? Because if I have valid, well-formed XML I can easily use XSLT to turn that into (X)HTML or SVG. I can also turn it into plain text if I want (I have XSLT stylesheets already, that choose to emit HTML fragments or cleanly-word-wrapped plain text depending on user selection).

There are plenty of ways to solve this particular problem, but the advantage that XML gives me in this case makes it the preferred choice (at least, for my preferences and my needs). XSLT is a well-defined, well-documented (OK, your opinion may vary on that with regards to the W3C documentation, but there is no shortage of books on the subject) tool for transforming XML into, well, pretty much anything. For this particular problem, the expressiveness of XML combined with the fact that my ultimate target formats (XHTML and SVG) are themselves XML, made it the clear choice. On the other hand, there have been plenty of times when I've recommended (as a consultant) to a client or (as a company employee/team member) to a boss/team that XML should not be used for some task. Sometimes the reason is clear-- using XML wouldn't improve the (re-)usability of the data, they weren't using XML on the project yet and this wasn't the sort of thing you should introduce that dependency for, etc. Sometimes the reason is more subtle; if you are trying to decide how to store/retrieve your application's configuration, does it really need to be in XML? It's highly unlikely any other application will need to read/parse this, so portability/reuse of data isn't an issue. If the data is fairly flat in nature you can probably manage with a file of key/value pairs. If the data is more complicated and/or complex, you might be fine with YAML.

In general, XML is the worst choice for data expression, except when it's the best choice. The same can be said for JSON and YAML, and the best way to get the most out of any of these approaches is to be familiar and comfortable with all of them and know which one is the best tool for the job you have in front of you.

rjray
Excellent (voted you up). Points for portability, parseability and tools. I really do strive to learn all the tools available to me. Have you looked at oslo enough to shine some light on that perspective?
Cristian Libardo
No, I haven't, to be honest. I work mainly on Linux and MacOS systems, though I try to avoid platform-specific pitfalls whenever I can.
rjray
+2  A: 

I think the magic word in the question is "declarative."

A declarative technology with any flexibility requires a format for declarations. It has to have a way of validating that the declarations are syntactically correct. It needs to be able to serialize and deserialize the underlying data structures into and out of this format. It's very beneficial if the format is sufficiently open that it's straightforward to build tools that generate, modify, or process the declarations.

You can see where this is going.

I think the problems you're seeing are real, but I don't think they're really XML problems. Well, not directly. I think the real problem lies with the other thing you said: the design tools for these declarative technologies aren't powerful enough.

And here's why it is, kind of, an XML problem: no developer who was using JSON as his product's serialization format would allow himself to think "hey, I don't need to implement this feature, the user can just edit the JSON."

I think that's the problem right there. It's not that XML's a bad format for representing declarations. It's that XML's openness is very seductive. It gives tool developers a way to skate by on leaving functionality out of their tools.

I think that's a social problem, not a technical problem. And it's a tough problem. We'd probably have much better WPF tools if instead of XAML Microsoft had come up with a closed format. But we get too much from open formats to give them up.

Robert Rossney
Interesting point about openness and XML. One of the challanges is the boundry between XML and the "other" language. It's never (and perhaps cannot be) smooth enogh.
Cristian Libardo