Andrey has reminded me that there are some advantages to XML, such as the ability to define an XSD and get intellisense, or to use standard stuff such as xinclude, out of preverse sense of curiousity, I tried to do this to an SSIS package:

I simple moved everything out to the xinclude.xml, wasn't surprised when it didn't work. A lot of the features of XML require an extra action on the side of the parsing code, such as explicitly asking for resolving XInclude, and most of the time that is never supported by the tools. And while XSD schema + intellisense is nice, do you really want to write something like an SSIS package using plain XML + intellisense?

In case you didn't notice, I don't like XML. To be rather exact, I don't like the way XML is used. If you are writing a document, it is a great way to skip parsing headaches, but seriously, is writing a parser that hard?

Case in point, SSIS packages are just XML, but they are literally binary XML, in that I have no way of really looking inside and figuring out what is going on. Oh, I can probably put it through a prettifier and then try to have a look-see, but that is a costly endevour, and not really practical for anything beyond getting the bloody connection string out of the file.

Just today I was looking at SSIS package, it was changed, but I have no idea what the change was, so I run a diff. It came back with a lot of changes, non of which told me, an occational (reluctant) dabbler of SSIS what the hell had happened.

Just this, the inability to understand what the hell has changed from a diff file, is a serious offence against the maintainability of most of the "no code" approaches (but reams of XML).

Urgh!

In other news, Boo got better support for creating DSLs.

I would really like to understand the attidute behind "no code* (TM) " approach.

* Except a whole lot of of XML that you are not supposed to look at but usually have.

The new announcement from Microsoft is hitting all the key points that scream "STOP" in my case:

I do believe that I have heard this promise before. About Object Oriented Programming, COM, XML, Web Services, SOA, etc.

Being a developer is about telling the computer what to do. Trying to hide this behind a wizard is nice, but it is not an approach that scales, period.

I am not going to program in this, but it looks like that is what I would need to do if I wanted to understand what is going on.

<CsamlFile xmlns="http://schemas.microsoft.com/winfx/2006/xaml/csaml"
           xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <NamespaceDeclaration Identifier="MyNamespace">
        <ClassDeclaration Identifier="MyClass" 
                          Access="Public">
            <MethodDeclaration Identifier="Main" 
                               Access="Public" 
                               Modifier="Static" 
                               ReturnType="{x:Type void}">
                <InvocationExpression
                  MemberAccess="System.Console.WriteLine">
                    <InvocationExpression.ArgumentList>
                        <Literal Type="{x:Type string}"
                                 Value="Hello, CSAML! ">
                    </InvocationExpression.ArgumentList>
                </InvocationExpression>
            </MethodDeclaration>
        </ClassDeclaration>
    </NamespaceDeclaration>
</CsamlFile> 

Oh wait, there is a designer?

Nice, I saw how that turned out for SSIS, BizTalk, etc when we are talking about even moderate complexity. How do I debug it? There is a special tool? How do I profile it? There is nothing for that?

Can we please stop trying to run away from code? If I want declerative language, I will write a DSL, and it sure as hell wouldn't be in XML.

I am all for smarter frameworks and making our life easier, but I am completely against trying to get to: "all without writing or generating any code"

Newsflash: XML is code, period.

A couple of commenters on my last post said that XML is easier to work with tool-wise. This is true in a very strict sense. Code is incredibly expressive, and you can easily turn it into an object graph by simply executing it. I did something very similar a year ago, Saving object graphs to file: CodeGen and Executable Graphs.

Lame title, but bear with me.

I have got a set of XML files that conform to an XSD schema, specifically, this one. I want to add additional elements and attributes to the documents, without breaking the schema, and hopefully without changing the code that read the schema.

Basically, I have this:

I have bolded the parts that I want to add to the document. Any suggestions?

How would you go about testing code that generate code? I can think of only those two approaches:

• Compare strings - very fragile.
• Compiling the generated code and test that - may be complex if what you are generating is basically helper code.

Anything else?

Continuing on the TDD list, this message from Robert Hanson has the best description of the goals of XP that I've ever read.

I wish I worked there too. Check out the replies, they contain some great discussion.

Recently I've think about trying out some of the cool things that Avalon lets you do.

I'm not a UI programmer (never mind what other people are trying to tell me :-) ), but the things you can do there are so impressive that I really itch to do something with them. The interesting part comes when you throw an XML database into the deal, since using XQuery and friends you may be able to generate the UI in the query level, so you could probably create a lot of interesting stuff just by playing with the data.

I've no idea if Avalon has the ability to generate the UI on runtime, or if it needs a compilation step like ASP.Net (I would tend to think so, but I really don't know any thing about it except that it looks cool). But if it can (and even if it can't) that should be a really cool project.

The Berkley DB XML is a free XML DB that looks nices, and it has .Net API (but not a free one). I'm thinking of buying a book about Avalon and writing some sample applications. And recommendations about that?

Anyone can comment about the general idea?

Faces is an interesting concept. I don't care for the software itself, but for the implementation. It's using python to config the project's options. This is a very flexible and natural way to do it.

No angle bracket in sight :-)