Ayende @ Rahien

Unnatural acts on source code

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

Andrey Shchekin
06/12/2007 04:47 PM by
Andrey Shchekin

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.

Andrey Shchekin
06/12/2007 04:47 PM by
Andrey Shchekin

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.

Ayende Rahien
06/12/2007 05:15 PM by
Ayende Rahien

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.

Jay Flowers
06/12/2007 05:31 PM by
Jay Flowers

I think this will work better for where MS technology is at the moment:

<!DOCTYPE cruisecontrol [ 

<!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>

Jay Flowers
06/12/2007 05:32 PM by
Jay Flowers

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>

Comments have been closed on this topic.