Bug 20532

I made an attempt to collect various issues in Ant (&
apisupport/layers) which were marked unfixable pending an XML API.

First rather simple draft is in CVS. It does not contain the most
required model issues :-(. 

Still, no idea how to expose/develop/sustain it without managerial
support.

I have found out that I should be interested. I'll post on dev@openide.

We are after feature freeze of 3.4. That should mean to have all
features reviewed, implemented, covered by tests and documented. I do
not think that this happened for the XML API and I am not sure how
likely that will happen.

Please consider rollback of the API so it will not appear in release34
branch.

Let these are considered while planning next release.

Target milestone was changed from not determined to TBD

Unscheduling from my todo list. New owner is gladly welcome. Meanwhile assigning
to abstract issues@xml.netbeans.org owner.

I'd like to ask what are people's current requirements for a potential
XML tools API.

- What things should it accomplish?
- Who would be the clients of this API?
- What would be the benefits?
- What needs to be changed compared to the current state?

Thanks.

Requirements from Ant include:

1. Ability to tweak the editor. This is really more of an editor
issue, but mentioned here for completeness: want to have a delegation
chain text/x-ant+xml -> text/xml -> text/plain, so Ant module can set
editor MIME type to text/x-ant+xml, then get regular XML abilities
(toolbar, context menu) plus its own (target toolbar, Ant context menu).

2. Ability to structurally manipulate an XML file using DOM or perhaps
some other tree API (but DOM preferred for its ubiquity - could add
minor helper APIs for details DOM does not cover). Must preserve exact
(char-by-char) formatting of document regions not logically affected
by a change, and avoid unnecessary textual changes in regions that are
affected by the change.

Should have option to automatically insert appropriate indentation
whitespace in newly created elements, or clean up whitespace
surrounding newly deleted elements.

Should also have a way of determining the document position (or just
line number) corresponding to a given element (or perhaps other node),
or the element corresponding to a given document position.

At this time I do not see any need for an API for tree visualization
(e.g. Node or Node.Property implementations) from the Ant module; just
a raw structure editing API would be enough, as the Ant module has its
own specialized display anyway which does not follow the XML structure.

3. Code completion APIs must be cleaned up (e.g. to not require you to
impl DOM interfaces as a client, since these change with every DOM
release), better documented (currently usable only by trial and
error), and stabilized (published w/ some assurances of compatibility,
using regular spec version dep).

3a. Support XML namespaces in code completion, for NS-aware grammars.

3b. Permit CC grammar to specify popup documentation (HTML format) for
a given completion item.

And of course I would not want to have to subclass some XMLDataObject
to get these capabilities. All such SPIs should be available
independently as needed by clients.

I guess this issue is obsolete.

*** This issue has been marked as a duplicate of 76045 ***

The issue is obsolete