Working with XML can be a wonderful experience. Most people I know (in the industry) don't consider XSD/DTD validation a task that is challenging enough so as to spend time and/or effort to either learning it or writing to it. This feeling changes rapidly as tooling support (e.g. IDEs) produces hiccups when XML validation generates errors that can not be understood by the same engineering staff. For example, have you ever had the infamous problem reported through Eclipse's console:
cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'custom-filter'.
By default Eclipse has XML validation on. This means that it will look for a DTD of XSD to validate your XML file. The message above indicates that there's an XML element named custom-filter that can not be resolved with any of the XSD that Eclipse is aware within it's catalog registry.
Now, most people I know turn off XML validation so as to not to deal with this problem. This is simply a terrible idea and bad practice. XSD definitions provide much richer ways to describe XML constructs, including comments. When the setup is properly configured, it can be a very handy tool (even for learning purposes). Craig Walls wrote a blog with instructions in how to add a new Catalog entry in Eclipse. The post can be found here. Note that you may find the same problem if you have an older version of Spring Source Tool Suite (STS) and are upgrading via the update site. The way I dealt with this is typically a full rebuild of my project so that STS (or Eclipse) can allow XML tooling to magically occur.
Hope this helps!
No comments:
Post a Comment