Xml: All the way or none at all
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:
<?xml version="1.0"?>
<DTS:Executable xmlns:DTS="www.microsoft.com/SqlServer/Dts"
DTS:ExecutableType="MSDTS.Package.1"
xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="file:///D:/xinclude.xml"/>
</DTS:Executable>
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?
Comments
You are right about this one -- xi is not supported by MS processors right now, so I should have used this as an argument. But there is two bonus points still: 1. it will occasionally get supported without any work form your side; 2. what is easier -- write an xslt that will do include for some of your files before sending them or parse vendor DSL to add include capability?
Also, talking of XSLT, you can use XSLT to make any cutomised report or representation of original file. Even nice-looking diff between 2 of them.
I see your point, and as for me, I may prefer DSL for my own config files/whatever, but it should be XML for most limited DS languages that are not owned by me and not open source.
You are right about this one -- xi is not supported by MS processors right now, so I should have used this as an argument. But there is two bonus points still: 1. it will occasionally get supported without any work form your side; 2. what is easier -- write an xslt that will do include for some of your files before sending them or parse vendor DSL to add include capability?
Also, talking of XSLT, you can use XSLT to make any cutomised report or representation of original file. Even nice-looking diff between 2 of them.
I see your point, and as for me, I may prefer DSL for my own config files/whatever, but it should be XML for most limited DS languages that are not owned by me and not open source.
1/ eventually is not a concern of mine, unless it is next week.
2/ parsing, naturally. Imperative logic, easy to follow & debug.
There is very little that needs to be done to build something like: #include "foo.bar"
And that is the most primitive of the include options.
I think this will work better for where MS technology is at the moment:
<!DOCTYPE cruisecontrol [
]>
<DTS:Executable xmlns:DTS="www.microsoft.com/SqlServer/Dts"
&include;
</DTS:Executable>
Oops that should be:
<!DOCTYPE Executable[
<!ENTITY include SYSTEM "file:D:/include.xml">
]>
<DTS:Executable xmlns:DTS="www.microsoft.com/SqlServer/Dts"
DTS:ExecutableType="MSDTS.Package.1"
xmlns:xi="http://www.w3.org/2001/XInclude">
&include;
</DTS:Executable>
Comment preview