This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Validation against schemas listed in an XML catalog does not work | ||
|---|---|---|---|
| Product: | xml | Reporter: | Jesse Glick <jglick> |
| Component: | Catalog | Assignee: | Milan Kuchtiak <mkuchtiak> |
| Status: | CLOSED FIXED | ||
| Severity: | blocker | CC: | johnjullion, pkuzel |
| Priority: | P2 | ||
| Version: | 4.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 27930 | ||
| Bug Blocks: | |||
|
Description
Jesse Glick
2004-08-26 21:51:17 UTC
So JJ, the *provisional* instructions for syntax checking your freeform project.xml are to insert xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.netbeans.org/ns/project/1 http://www.netbeans.org/ns/project/1.xsd http://www.netbeans.org/ns/freeform-project/1 http://www.netbeans.org/ns/freeform-project/1.xsd http://www.netbeans.org/ns/freeform-project-java/1 http://www.netbeans.org/ns/freeform-project-java/1.xsd http://www.netbeans.org/ns/freeform-project-web/1 http://www.netbeans.org/ns/freeform-project-web/1.xsd" into the root element of the XML document. This will enable A-S-F9 to correctly validate it. Hopefully this issue will be resolved so that it will be possible to validate such files in an easier manner. (Note that code completion for schema-controlled files is however absent in NB 4.0 due to lack of development on XML-related functionality.) Consider this serious; cannot get basic functionality of XML catalog support to work. In fact I see 2 goals here : 1/ ability to validate project.xml files (with proxy) 2/ ability to validate project.xml files (without proxy) 1/ To achieve the first goal we should keep the standard xml aproach : specify the xsi:schemaLocation attribute in XML document. Without the xsi:schemaLocation (Xerces) parser is not able to find the XML schema without additional hacks to validate action. (I am not for such a solution). I think, the standard solution would be to include the xsi:schemaLocation attributes to elements at proper place e.g. : =================================================================== <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://www.netbeans.org/ns/project/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.netbeans.org/ns/project/1 http://www.netbeans.org/ns/project/1.xsd"> <type>org.netbeans.modules.java.j2seproject</type> <configuration> <data xmlns="http://www.netbeans.org/ns/j2se-project/1" xsi:schemaLocation="http://www.netbeans.org/ns/j2se-project/1 http://www.netbeans.org/ns/j2se-project/j2se-project.xsd"> <name>javaLib</name> <minimum-ant-version>1.6</minimum-ant-version> </data> </configuration> </project> ================================================================== that means not put all the schemaLocation pairs to the beginning of the document(as Jesse suggested) 2/ To achieve the second goal the first goal must be implemented. Then it is possible to map particular SystemIds to local uris. See the recommendation in XML Oasis Catalog template. Thus, I would devide this bug to partial bugs for each project type : to update the generated project.xml files. Strictly said the validation against XML schema, using the XML catalog, works if properly set up. BTW, I thing the XML catalog should be used for specifying local resources, not the resources on the web. The catalog mapping (mentioned by Jesse) : <uri name="http://www.netbeans.org/ns/project/1" uri="http://www.netbeans.org/ns/project/1.xsd"/> works with the Apache Resolver1.1 version. Actually we use the own Catalog implementation independent from org.apache.xml.resolver.Catalog. We should switch from the own version of Catalog to the standard one. I am working on that. See also : issue 40339 issue 27930 If possible, I would prefer a solution that does not require the explicit schemaLocation attribute - this attribute ought to be unnecessary if you are using the proper catalog. Right? If so, I think that is all that counts - that is what needs to be implemented. Re. proxied vs. unproxied network access - irrelevant, network access works fine through a proxy if you have configured it. As far as offline usage goes, of course it would be preferable to use a local schema if one is available. But this can be done by the catalog author; nothing in particular is needed from the xml/catalog module. As far as project.xml files : Is there a requirement from the user perspective to validate these files ? If yes and even when this bug is fixed : who will be responsible for creating catalogs ? If there will be no catalogs (pre)installed the xsi:schemaLocation is necesary to find XML schema files. "Is there a requirement from the user perspective to validate these [project.xml] files?" - yes, somehow. Current workaround is to manually insert schemaLocation attributes. "who will be responsible for creating catalogs?" - me. I would like to be able to tell users to simply mount the catalog at http://www.netbeans.org/dtds/catalog.xml and have everything work. Of course some module could preinstall this catalog as well. Fixed. The <uri .../> mappings should work. Diffs : xml/api : http://xml.netbeans.org/source/browse/xml/api/src/org/netbeans/spi/xml/cookies/SharedXMLSupport.java.diff?r1=1.5&r2=1.6 http://xml.netbeans.org/source/browse/xml/api/src/org/netbeans/spi/xml/cookies/ShareableInputSource.java (new file) xml/catalog : http://xml.netbeans.org/source/browse/xml/catalog/src/org/netbeans/modules/xml/catalog/spi/CatalogReader.java.diff?r1=1.2&r2=1.3 http://xml.netbeans.org/source/browse/xml/catalog/src/org/netbeans/modules/xml/catalog/CatalogEntityResolver.java.diff?r1=1.10&r2=1.12 http://xml.netbeans.org/source/browse/xml/catalog/src/org/netbeans/modules/xml/catalog/impl/SystemCatalogReader.java.diff?r1=1.5&r2=1.6 http://xml.netbeans.org/source/browse/xml/catalog/src/org/netbeans/modules/xml/catalog/impl/sun/Catalog.java.diff?r1=1.6&r2=1.7 ufff.... Anyone is wiling to help me verify this issue? Jesse, Milan? Sounds little complicated to me. Need more step by step scenario, pleease. With the Milan's help we successfuly verify it on his linux box and then me on the WinXP (latest DEV (4.0) build #200409131800). It's only in TRUNK, not in latest Q-build branche. Yes, seems to be working as desired in 040921 custom. Thanks! Note: an incompatible change was made to CatalogReader (added methods to an interface in a publicly accessible package) without marking the xml/catalog module as having changed incompatibly (/2 -> /3), in violation of NB API guidelines, and causing at least contrib/docbook to be broken. |