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 20532 - Create XML tools APIs
Summary: Create XML tools APIs
Status: VERIFIED DUPLICATE of bug 76045
Alias: None
Product: xml
Classification: Unclassified
Component: API (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker with 6 votes (vote)
Assignee: issues@xml
Keywords: API
Depends on: 14207 14296 14445 15261 15773 17297 17699 19789 26478 14204 15756 17597 17861 17868 18488 19228 19491 20191
Blocks: 8864 9969 10219 10906 13120 16102 17683 18171 20269 20270 20792 21250 26524 42859
  Show dependency tree
Reported: 2002-02-14 10:24 UTC by _ pkuzel
Modified: 2008-04-19 11:06 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2002-02-14 10:24:56 UTC
Design them as maximaly decoupled from DataObject. Some users may simply need to
define a MultiDataObject and still reuse the infrastructure.

May be XMLDataObject should not be even public!
Comment 1 Jesse Glick 2002-03-01 14:19:43 UTC
I made an attempt to collect various issues in Ant (&
apisupport/layers) which were marked unfixable pending an XML API.
Comment 2 _ pkuzel 2002-04-17 17:13:20 UTC
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
Comment 3 Jaroslav Tulach 2002-04-18 09:00:34 UTC
I have found out that I should be interested. I'll post on dev@openide.

Comment 4 Jaroslav Tulach 2002-05-16 17:32:48 UTC
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
Comment 5 _ pkuzel 2002-06-03 12:26:39 UTC
Let these are considered while planning next release.
Comment 6 Marek Grummich 2002-07-19 16:03:44 UTC
Target milestone was changed from not determined to TBD
Comment 7 _ pkuzel 2003-09-03 11:10:44 UTC
Unscheduling from my todo list. New owner is gladly welcome. Meanwhile assigning
to abstract owner.
Comment 8 Petr Jiricka 2004-10-18 15:26:13 UTC
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?

Comment 9 Jesse Glick 2004-10-18 20:21:16 UTC
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.
Comment 10 Jesse Glick 2006-07-20 05:27:56 UTC
I guess this issue is obsolete.

*** This issue has been marked as a duplicate of 76045 ***
Comment 11 Mikhail Matveev 2008-04-19 11:06:39 UTC
The issue is obsolete