I need a format for the documents stored by AppMakerX that allows for storing abstracted interface documents. The format needs to store a sufficiently flexible UI description to allow for mutating objects and people sketching vague interfaces where they know something might be in a given place but aren’t sure what type of control they want. The question is whether XAML is sufficiently flexible to fill this role because having a tool-chain that works with XAML is attractive from a marketing position. Continue reading
There’s been an interesting thread over on the Artima Forums – How Will You Use XML in the Years to Come? I’m not writing this post on my Artima Blog because I wanted to bring XML issues to a different audience and there seems to be a fairly bigoted crowd over there, largely from the Java community. I can get into fights with enough people there on the comment threads.
The funny thing is, when I’ve become involved in similar threads in the past, it seems many of the people commenting are anti-XML because of experiences either dealing with relatively small configuration files or other domains where the benefits of schema checking aren’t perceived due to the small file size. It may be that Java developers are soured on XML by the Ant syntax but the whole configuration files in XML debate isn’t really about XML so much as it is about the issues of wholly-declarative make files. Martin Fowler has a nice bliki entry The thing with build scripts is that you need both declarative and procedural qualities. The heart of a build file is defining tasks and the dependencies between them. This is the declarative part, and is where tools like ant and make excel. The trouble is that as builds get more complex these structures aren’t enough. You begin to need conditional logic; in particular you need the ability to define your own abstractions.
One of the perennial issues that crops up with XML is the painful redundancy in having to enter those closing tags, raised by people with a Lisp background (simple parens instead of opening and closing tags) and indentation fans such as the YAML crowd. It was ironic to read a posting recently from someone encountering the main reason for the redundant closing tags – they catch your errors! But one thing which came in handy which I didn’t expect was that because of XML’s redundancy, the parser caught my mistakes in missing closing tags and pointed them out at the location that they occurred.
The posting is worth reading as it starts as someone speaking with no agenda and seeming surprised by the conclusion they come to – XML ain’t that bad.
Whatever is being used, I want my configuration and other exchange data to provide two characteristics:
- I can effectively subclass the existing code by being able to add my own annotations and nested clauses in the data, without worrying about breaking their parser or having to maintain their code.
- Bits of data should survive being copied and pasted from emails and web pages. This happens very often as we reuse advice from web pages or passed on by friends or mailing lists. Anything relying on whitespace for meaning is under threat (yes, I include Python, which I use happily in many circumstances but has a real problem here).
Given that XML satisfies these two conditions and has lots of free tools out there including stuff for command-line validation (given schemas), I don’t feel the desparate need to replace it. I’m not exactly a fan of the W3C XML Schema XML-based language for schema definitions but it serves a reasonable job much of the time and again, there’s a substantial body of tools that avoid having to write schemas by hand any more. People in the OGC (geo-spatial) community typically work in visual models and generate XML Schema.