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.

Bug 48029 - Validation against schemas listed in an XML catalog does not work
Summary: Validation against schemas listed in an XML catalog does not work
Alias: None
Product: xml
Classification: Unclassified
Component: Catalog (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Milan Kuchtiak
Depends on: 27930
  Show dependency tree
Reported: 2004-08-26 21:51 UTC by Jesse Glick
Modified: 2007-09-25 01:30 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-08-26 21:51:17 UTC
040824. I may be doing something wrong, but if so,
there is no indication what.

I have a freeform project.xml file. It uses the
namespaces "",
in the usual way.

If I use xsi:schemaLocation attributes on the root
element, I can force it to locate appropriate XML
schemas for these namespaces when I press
Alt-Shift-F9 to validate.

But without modifying the project.xml to point to
the schemas explicitly, I am unable to get it work.

In particular, by specifying in the root element:

<project xmlns=""

then validation proceeds correctly (and detects
errors when appropriate).

But if I use the plain header, with no schema
location imformation:

<project xmlns="">

then I get the error:

cvc-elt.1: Cannot find the declaration of element
'project'. [2] 
XML validation finished.

even when I have configured an OASIS XML catalog
in the XML Catalogs node in the Runtime tab with URL

which should be doing the same thing, via entries
such as

<uri name=""
Comment 1 Jesse Glick 2004-08-26 22:04:25 UTC
So JJ, the *provisional* instructions for syntax checking your
freeform project.xml are to insert


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.)
Comment 2 Jesse Glick 2004-09-02 14:34:34 UTC
Consider this serious; cannot get basic functionality of XML catalog
support to work.
Comment 3 Milan Kuchtiak 2004-09-06 15:53:10 UTC
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)

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=""
       <data xmlns=""
that means not put all the schemaLocation pairs to the beginning of
the document(as Jesse suggested)

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.
Comment 4 Milan Kuchtiak 2004-09-06 17:13:05 UTC
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.
Comment 5 Milan Kuchtiak 2004-09-07 12:56:31 UTC
The catalog mapping (mentioned by Jesse) :

<uri name=""

works with the Apache Resolver1.1 version.

Actually we use the own Catalog implementation independent from

We should switch from the own version of Catalog to the standard one.
I am working on that.

See also :
issue 40339
issue 27930
Comment 6 Jesse Glick 2004-09-07 17:56:03 UTC
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
Comment 7 Milan Kuchtiak 2004-09-08 07:48:18 UTC
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.
Comment 8 Jesse Glick 2004-09-08 15:41:34 UTC
"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

and have everything work. Of course some module could preinstall this
catalog as well.
Comment 10 dmladek 2004-09-14 16:33:42 UTC
ufff.... Anyone is wiling to help me verify this issue? Jesse, Milan?
Sounds little complicated to me. Need more step by step scenario, pleease.
Comment 11 dmladek 2004-09-14 17:21:39 UTC
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.
Comment 12 Jesse Glick 2004-09-21 21:40:29 UTC
Yes, seems to be working as desired in 040921 custom. Thanks!
Comment 13 Jesse Glick 2005-01-13 22:12:25 UTC
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.