[mountjoyj]

Hi all,

Why is there no support for XML catalogs? Right now, DTD support is a bit of a mess. XML catalogs have been around for a while now, and are supported by most XML editors.

The current support is a shambles (having to have to manually download DTD files, rename them, and put them in a special directory!)

Any idea if/when this will happen?

[Riyad Kalla]

having to have to manually download DTD files, rename them, and put them in a special directory!

I don’t know that this is an accurate assessment of the existing DTD support. Please keep in mind that this is only done when the DTD auto-download fails. This is typicall due to a proxy not allowing it to pull down the DTD file. Assuming no network anomolies, referencing a new DTD (typing it in the DOCTYPE at the top of the XML file) automatically downloads/stores/parses it for use immediately. We would hope that this automated approach is far from “shambles” to our users…

Why is there no support for XML catalogs?

Demand and Time Constraints are probably why. But that certaintly wouldn’t stop us for going back and having a look to see where this can improve. I am not farmiliar with XML Catalogs, but if support is non-transparent, meaning that it provides some additional potential for interaction with the user, then can you give a detailed use-case of what you would be looking for in way of support? The more details our users give when requesting a feature, the easier it is for us to approach and deliver closer to their expectations.

[mountjoyj]

Sorry for “shambles”, but I think it is far more than simply a pain in the butt 🙂
You expect every user of MyEclipse to physically download, rename, and place in a directory. This causes all sorts of ugly problems.
1) The directory is a MyEclipse directory
2) What if the DTD changes?

The whole point of catalogs are to map an external entity’s public identifier and/or system identifier to a URI reference.

I should be able to simply tell MyEclipse where the catalog file is. That’s minimum support. Now:
1) My catalog can be stored in my own directories. No need to hack yours.
2) The catalog can be changed if the DTD changes, perhaps referring to a different physical file representing the DTD. Again, I shouldn’t hvae to hack my IDE to do this.
3) The catalog can be shared – by all other users. Instead of forcing all users of MyEclipse to make directory changes.
4) The catalog can be shared amongst all users using OTHER editors – because catalog format is standard.

You can learn more here:
Spec – http://www.oasis-open.org/committees/entity/spec-2001-08-06.html
Article on JAXP and catalog resolution – http://www.xml.com/pub/a/2004/03/03/catalogs.html

This last one has pointers to code and implementation….

(In terms of Eclipse, I would imagine being able to set a catalog properties file for each Eclipse project.)

Hope this helps..

[Scott Anderson]

DTD caching has been enhanced for version 2.8 in such a way that most download failures will now be avoided. As a result, it should now work completely invisibly to most users, requiring no configuration at all.

[mountjoyj]

Thanks for the pointer. While I do appreciate the DTD caching feature (a non-standard approach to a common problem), it provides little benefit compared to the catalog approach (a standard approach to a common problem), as I outline above.

[Author]

Posts