views:

573

answers:

2

In a previous question I mentioned some work with a 3rd party DLL whose interface uses a series of XML inputs that are defined using DTDs. Everything has gone smoothly so far, but I still have this nagging issue with resolving the Document Type Declaration in the generated input values.

What I can't figure out is what the deciding factor is in determining where to look for the referenced DTD file. If I have a declaration that looks like this:

<!DOCTYPE ElementName SYSTEM "ElementName.dtd">

My initial thinking was that the application's current execution path is where a parser would look for the DTD. However, when I attempt to use an XML control in ASP.Net, the error I get baffles me...

Could not find file 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ElementName.dtd'

Why is it looking for the DTD there?

Are there any XML gurus out there who can help me out on this one. I really don't have any control over the XML that is returned from this DLL so what am I supposed to do. Is there a way to "register" a DTD with the operating system? Like the GAC?

+1  A: 

Unfortunately the library that generated the XML used a relative url for the dtd rather than a fully qualified one. As such the XmlControl's XmlDocument is using an XmlResolver class to convert the relative path to a fully qualified one. By default it uses an XmlUrlResolver (that is a concrete XmlResolver). This will try to map the location of the dtd to a location it thinks is relative to the Xml document. Trouble is, where is the XmlDocument? Probably in memory which is not relative to anything and the XmlUrlResolver is using the process location instead which in your case is Visual Studio which is located at 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe'.

So what can you do? Well I suppose you have to crate you own XmlResolver that inherits from XmlUrlResolver an overrides the ResolveUri method and does something appropriate. Having done that you will have to:

  1. Create an XmlReaderSettings class and set the XmlReolver property to the class you just created.
  2. Create an XmlReader using XmlReader.Create() passing in your document and the XmlSettings object.
  3. Create an XmlDocument and call Load passing in the XmlReader and finally.
  4. Set the XmlDocument property of your XmlControl to the XmlDocument.

Frankly that is all a bit of a pain, so if it where me I would just use string.Replace to remove the DTD declaration from the document before processing it into XML.

If you are feeling really brave you can create a resolver that inherits directly from XmlResolver. Once you have done that you can override the GetEntity method and then you can get the dtd document from wherever you like. I wrote one once that got dtds from files embedded as resource files, but unfortunately, I don't have the code any more :-(

Martin Brown
Wow! I can only imagine you must have gone through all this pain once before to be able to offer such detailed advice on the problem. Yeah I figured as much about the visual studio thing because I was running Cassini, and got nervous about where I would need the dtd once deployed to the server. IIS?
Josh
(cont.) It ended up that yes, I did have to dump the dtd out in the IIS execution path, but this is a huge cluster F! I am very appreciative of this advice however, because it will allow this project to be much more maintainable :)
Josh
A: 

If you do not actually care about validating each and every document against its DTD, you could set the XmlResolver property to null on your XmlTextReader (or XmlDocument) to ignore the DTD altogether.