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 38340 - Add namespaces support to DefaultContext
Summary: Add namespaces support to DefaultContext
Status: NEW
Alias: None
Product: xml
Classification: Unclassified
Component: Text-Edit (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@xml
Depends on:
Reported: 2003-12-29 00:25 UTC by Jesse Glick
Modified: 2007-09-25 01:33 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-12-29 00:25:37 UTC
The HintContext Javadoc doesn't talk about XML
namespaces support at all, but it is clear from
the impl in DefaultContext that there is none:

public String getNamespaceURI() {
    throw new UOException();

For some kinds of grammar providers this may be a
serious deficiency. E.g. Ant 1.6 introduces
support for namespaces in various forms; in order
to support completing elements in a
namespace-aware fashion, it may be necessary to
have the XML module grok them. For example, if you
have a script

<project default="x">
    <typedef file="mylib.xml" uri="urn:foo"/>
    <target name="x">
        <!-- CURSOR HERE -->

and mylib.xml contains

    <taskdef name="foo" classname="Foo"/>

then an appropriate completion would be

    <f:foo xmlns:f="urn:foo"/>


    <foo xmlns="urn:foo"/>

or just


if xmlns:f="urn:foo" is added to <project>.

It would be possible - with a fair amount of extra
work - to implement the first or second
possibilities in the GrammarQuery provider, rather
than the xml/text-edit module, if this clause from
the GrammarResult Javadoc

"It can have children representing mandatory
content. However it is up to client if it uses the
mandatory content."

guaranteed anything: you could manually examine
the document tree looking for existing namespace
prefixes, and if necessary add one on the element
itself. Unfortunately it seems that
ElementResultItem in fact ignores any content and
pays attention only to the element name:

public ElementResultItem(GrammarResult res) {
    foreground =;
    startElement = true;

So unless I am missing something, it is impossible
in general to provide correct namespace-aware XML
completion with the current API implementation. I
guess you could try to return an Element
GrammarResult with a "name" like

   "f:foo xmlns:f=\"urn:foo\""

But this is an awful hack, and it will not work if
xml/text-edit attempts to insert a close tag.

Note: XSLGrammarQuery does provide completion on
elements in the namespace with whatever
namespace prefix. However it needs to manually
interpret prefixes and xmlns attributes. (See
updateProperties().) And this trick will only work
if the document already has a defined prefix for
the element to be completed - not a problem for
XSLGQ since this will hold for stylesheets, but a
problem for Ant scripts where it cannot be assumed
that the user has already defined namespace prefixes.
Comment 1 Milan Kuchtiak 2004-02-27 09:23:32 UTC
It looks more like an enhancement.
Comment 2 _ pkuzel 2004-08-03 16:59:24 UTC
DOM level 2 and NS support is RFE. In fact it'll be hard needed for
XMLSchema completion support.
Comment 3 Jesse Glick 2004-08-03 17:53:29 UTC
Note also that 4.0 project types, esp. the freeform project type, use
schema-controlled XML files. To permit code completion on these we
should stabilize and productize the xml/schema module.
Comment 4 Marek Fukala 2007-02-16 14:46:03 UTC
Reassigning to default owner of selected subcomponent. New owners are gladly