File: TODO.txt

package info (click to toggle)
libjdom0-java 0.9b-1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 7,148 kB
  • ctags: 3,104
  • sloc: java: 9,604; xml: 595; makefile: 49; sh: 33; perl: 31
file content (323 lines) | stat: -rw-r--r-- 14,980 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
Items that need to be done:

--- API CHANGES FOR 1.0 ---

* Look at Brad's experimental tree for good ideas to integrate.
  ftp://a.cs.okstate.edu/pub/hip/jdom-x.zip

* Make sure the filter classes have hashCode() methods.

* Add DocType to the content list returned by Document so it can have a
  location.  Fix the outputters and builders to respect it.  Keep the easy get
  method however.

* Look at interfaces for the core classes, Element with ConcreteElement being
  our code.  Base on the factory model.  Allow no access between objects
  except using the public API, to avoid the import node problem.  Do the big
  switchover using javax.xml.jdom as interfaces and default impl, use org.jdom
  for the concretes.  May not need to break existing code (sick and wrong).
  - read-only?

* Strategy pattern for XMLOutputter and others.
    If need for override, make others final and leave the protected.

* Make transforming easier, with a one-line method.

* Should there be ValidityException and MalformedException subclasses of
  JDOMException?  Elharo has a proposal.

* Finalize the XPath class interface.  Possibly take calls into Element,
  Document, etc.

* Add methods to recursively get content and get filtered content.

* Figure out how to deal with XMLOutputter writing of special characters like
  &#160.  Should it char escape only chars unprintable in the current
  character set?  Should there be a fancy API for selecting what's escaped?
  Should this be something where you can subclass?
  http://lists.denveronline.net/lists/jdom-interest/2001-February/004521.html
  http://lists.denveronline.net/lists/jdom-interest/2001-April/005644.html
  http://lists.denveronline.net/lists/jdom-interest/2001-April/005649.html
  http://lists.denveronline.net/lists/jdom-interest/2001-April/005669.html
  Alex proposal:
    http://www.servlets.com/archive/servlet/ReadMsg?msgId=334148
  Brad proposals:
    http://www.servlets.com/archive/servlet/ReadMsg?msgId=334184
    http://www.servlets.com/archive/servlet/ReadMsg?msgId=312047

* Look at where Namespace may need to be synchronized or made no longer a
  flyweight.  See
  http://lists.denveronline.net/lists/jdom-interest/2000-September/003009.html
  and follow-ups.

* Look into how the factory builder model could support giving the factory
  extra knowledge about the context (line number, element stack, etc), and 
  allow it to report errors or to return a code indicating the element should 
  be ignored.
  (Laurent Bihanic wrote JH a private email about this on Dec 28 2001.)

* Figure out if there's a role for a Node interface.  It sounds easy but all 
  attempts so far have hit obstacles.  Amy Lewis talks about it here:
  http://lists.denveronline.net/lists/jdom-interest/2000-December/004016.html
  There were many follow-on threads.

* Consider moving JDOMFactory to org.jdom.

* Investigate serialization issue raised by Tom Preston
  http://lists.denveronline.net/lists/jdom-interest/2002-March/009857.html

* Look into hasContent() and hasAttributes() methods to eliminate need to
  create lists during output.

* Start shipping Xerces 2.0+
  Xerces 2.0.0 bugs found when using DOMBuilder:
   * In cdata.xml we're getting entity callbacks for chars inside CDATA
     sections (bug 6316 in Xerces' Bugzilla, fixed Feb 2002)
   * In web.xml we're seeing the comments from the external DTD appear in our
     document (bug 6317 in Xerces' Bugzilla, fixed 13 Mar 2002)

* Performance optimize.  See following thread for test data.
  http://lists.denveronline.net/lists/jdom-interest/2000-October/003418.html
  http://lists.denveronline.net/lists/jdom-interest/2000-October/003472.html
  One idea: Stop using synchronized Stack in SAXHandler.

* Give attributes the "specified" flag like in DOM.  This probably isn't
  receivable from SAXBuilder, but it would be from DOMBuilder and other
  builders.  Then give XMLOutputter the ability to avoid outputting
  "unspecified" attributes.  Some of this may be covered by the attribute type
  support recently added.

* Look into implementing an id() method now that we have attribute types.

--- FOR JDOM 1.0 COMMUNITY REVIEW ---

* Expand class-level Javadocs for inclusion into Frame using the MIF Doclet.

* Note in the docs where necessary our multithreading policy.

* Add in attribute type support to DOM to match what's in SAX.

* Think about if XMLOutputter should have a few specific output states, like
  RAW, PRETTY, COMPRESSED.  See the thread "XMLOutputter inserts extra empty
  lines" for some discussion.

--- FOR JDOM 1.0 ---

* Write a "GNU JAXP (i.e. AElfred) DOM adapter" (elharo looking into this).

* Create "build dist" for distribution
  Use fixcrlf in dist (instead of package as currently done)
  Probably include source with jdom.jar built

* Consider changing XMLOutputter to have more set methods like Enhydra's
  DOMFormatter.  Possible good ones:
   void setPreserveSpace(boolean preserve) 
                       Set the default space-preservation flag.
   void setXmlEncoding(java.lang.String newXmlEncoding) 
                       Set the encoding using the XML encoding name.
   void setXmlEncoding(java.lang.String newJavaEncoding,
                       java.lang.String newXmlEncoding) 
                       Set both the XML and Java encodings.

* Consider adding methods/logic to Verifier for all XML spec. constraints
  (Consider specifically a PCDATA check.  Downside is Elliotte says it 
   causes a 20% performance penalty on building docs.)
  Probably go with sanity checking input unless it adds significant time to
  a SAX build.
  See http://lists.denveronline.net/lists/jdom-interest/2000-August/002088.html
  And http://lists.denveronline.net/lists/jdom-interest/2000-August/002102.html

* Consider changing the Verifier method signatures to throw the
  IllegalXXXException directly instead of returning null on error,
  and let the caller pass the exception through

* Populate jdom-test.  Jools is leading this but Phil Nelson is currently
  doing a lot of work.  Hong Zhang <Hong.Zhang AT Sun.COM> is helping with the
  J2EE CTS.

* Ensure JDOM is appropriately tweaked for subclassing, per the threads
  started by Joe Bowbeer.
  http://www.servlets.com/archive/servlet/ReadMsg?msgId=7601 begins it

* Ensure JDOM is flawless regarding clone semantics, per more threads by
  Joe Bowbeer.
  http://www.servlets.com/archive/servlet/ReadMsg?msgId=7602 begins it

* Joe summarizes his issues at
  http://www.servlets.com/archive/servlet/ReadMsg?msgId=7697

* Clean up Javadocs right before final release.

--- FOR JDOM 1.1 ---

* Consider visitor pattern
  Use cases: count elements, count nodes, translate comments, remove PIs
  Would implement with option to visit depth or breadth first
  Maybe go crazy with pre-order, in-order, and post-order too :-)
  Methods would exist on Document and Element
  FYI, DOM's much overweight Traversal-Range spec is at
    http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/
  Joe Bowbeer has ideas at:
  http://lists.denveronline.net/lists/jdom-interest/2000-November/003610.html
  We may be able to just have doc.iterator() methods
  Also see posts with the subject "How to ease traversal of JDOM tree"

* Add setIgnoringAllWhitespace(boolean) method.

* Investigate a way to do in-memory validation.  First step is probably 
  to get an in-memory representation of a DTD as per
  http://xmlhack.com/read.php?item=626
  http://www.wutka.com/dtdparser.html
  http://lists.denveronline.net/lists/jdom-interest/2000-July/001431.html
  http://lists.denveronline.net/lists/jdom-interest/2001-February/004661.html
  Maybe new DTDValidator(dtd).validate(doc);
  Then later new SchemaValidator(schema).validate(doc);
  Could instead do doc.validate(dtd/schema) but then we'd have to dynamically 
  switch between recognizing DTDs and the various schemas.
  The method would probably either throw InvalidDocumentException or might
  take an ErrorHandler-style interface implementation if there are non-fatal
  errors possible.
  It'd also be possible to have a programmatic verifier, that determined for
  example if an orderid="100" entry was valid against a database entry.
  http://dcb.sun.com/practices/devnotebook/xml_msv.jsp
  http://www.sun.com/software/xml/developers/multischema/

* Consider a listener interface so you could listen to doc changes.  
  (Probably after 1.1 honestly; this can be done through manual subclasses
  already.)  Some pertinent messages on this topic:
  http://lists.denveronline.net/lists/jdom-interest/2000-July/001586.html
  http://lists.denveronline.net/lists/jdom-interest/2000-July/001587.html
  http://lists.denveronline.net/lists/jdom-interest/2000-July/001600.html

* Consider a "locator" ability for nodes to remember the line number on which
  they were declared, to help debug semantic errors.
  http://lists.denveronline.net/lists/jdom-interest/2000-October/003422.html

--- UNTIED TO A JDOM VERSION ---

* Consider an XMLOutputter flag or feature to convert characters with well
  known named character entities to their named char entity form instead of
  numeric.

* Determine if DOMBuilder and DOMOutputter should transparently support DOM1.

* Perhaps have builder flags to indicate if CDATA sections should be 
  included and if comment sections should be included.  All seem like 
  reasonable customizations.  The whitespace flag may respect xml:space.  
  It might use an XMLFilter to do the job.

* Create a builder based on Xerces' XNI, which will be more featureful and
  probably faster than the one based on SAX.
  See http://lists.denveronline.net/lists/jdom-interest/2001-July/007362.html
  Some existing SAX limitations which hurt round-tripping:
  * Can't tell if attribute values are included from the DTD, because SAX
    doesn't tell if attributes are standalone/implicit
    (See http://www.saxproject.org/apidoc/org/xml/sax/ext/Attributes2.html)
    (Thought: could use a bit in the type value to save memory)
  * Can't get access to retain the internal dtd subset unless entity 
    expansion is off

* Contribute the samples from Elliotte's XML DevCon talk to the samples/
  directory.  http://metalab.unc.edu/xml/slides/xmlsig/jdom/JDOM.html

* Add a search for jdom.org using Google with site:www.jdom.org, imitating
  http://www.zope.org/SiteIndex/searchForm

* Fix it so check-in messages include diffs.  (jools AT jools.org)

* Add ElementLocator to contrib/ directory (from Alfred Lopez)

* Write a guide for contributors.  Short summary:
    Follow Sun's coding guidelines, use 4-space (no tab) indents, no lines
    longer than 80 characters

* Consider a builder for a read-only document.  It could "intern" objects to
  reduce memory consumption.  In fact, interning may be good for String
  objects regardless.

* Consider having the license be clear org.jdom is a protected namespace.

--- WILD IDEAS ---

* Think about somewhat crazy idea of using more inheritance in JDOM to allow
  lightweight but not XML 1.0 complete implementations.  For example Element
  could have a superclass "CommonXMLElement" that supported only what Common 
  XML requires.  Builders could build such elements to be faster and lighter 
  than full elements -- perfect for things like reading config files.  Lots
  of difficulties with this design though.

* Look at Xerces parser features (http://apache.org/xml/features/dom) for
  ideas on things that may be needed.
  http://xml.apache.org/xerces-j/features.html

* Create a JDOM logo.

* Create a Verifier lookup table as an int[256] growable to int[64K] where 
  bits in the returned value indicate that char's ability to be used for a
  task.  So "lookup[(int)'x'] & LETTER_MASK" tells us if it's a letter
  or not.

* Consider elt.getTreeText() which would recursively get the text (in order) 
  for the subtree, effectively ripping out interveneing Elements.  (Suggested
  by Bob to help with XPath.)

* Shouldn't addNamespaceDeclaration() have a name to match
  getAdditionalNamespaces().

* Consider an HTMLBuilder that reads not-necessarily-well-formed HTML and
  produces a JDOM Document.  The approach I'd suggest is to build on top of
  JTidy first.  That gives a working implementation fast, at the cost of a 
  157K Tidy.jar in the distribution.  After that, perhaps someone would lead 
  an effort to change the JTidy code to build a JDOM Document directly, 
  instead of making a DOM Document or XML stream first.  That would be a lot 
  faster, use less memory, and make our dist smaller.  See
  http://www.sourceforge.net/projects/jtidy for Tidy.

* Look at a (contrib?) outputter option using SAX filters per
  http://lists.denveronline.net/lists/jdom-interest/2000-October/003303.html
  http://lists.denveronline.net/lists/jdom-interest/2000-October/003304.html
  http://lists.denveronline.net/lists/jdom-interest/2000-October/003318.html
  http://lists.denveronline.net/lists/jdom-interest/2000-October/003535.html

* Look at event-based parsing as per the following thread:
  http://lists.denveronline.net/lists/jdom-interest/2000-November/003613.html
  and replies.
  Also see posts with the subject "streamdom".

* Considering that local vars are considerably faster that instance vars, test
  if using local vars can speed building.

* Consider a builder.setFeature() pass-through method that allows any 
  features to be set that aren't in the http://xml.org namespace.  Make
  those in http://xml.org not to be touched because either we have specific
  requirements for them to be set one way, or we have the feature exposed
  through a Java method.

* Consider Mike Jennings' proposal of two new methods on Element:
  public String getAttributeValue(String name, String default)
  public String getAttributeValue(String name, Namespace ns, String default)
  http://lists.denveronline.net/lists/jdom-interest/2000-December/004155.html

* Consider using a List of instance data so elements only use what they really
  need (saving attrib list, namespace list)

* Investigate doc.getDescription() to let people add doc descriptions.  It's
  an idea from IBM's parser suggested by andyk.

* Work on creating a deferred builder that parses only what's necessary to
  satisfy the programmer's requests.  See Ayal Spitz' post at
  http://lists.denveronline.net/lists/jdom-interest/2001-April/005685.html

* Create an HTMLOutputter to handle the HTML specific aspects (closing tags,
  escaped characters like &eacute;, etc).

* Add Laurent's <?javax.xml.transform.disable-output-escaping?> 
  and <?javax.xml.transform.enable-output-escaping?> support

* Fix the sorting problem.
  Alex idea: http://www.servlets.com/archive/servlet/ReadMsg?msgId=211785

* Change the various setAttributeValue() methods in Element and 
  Attribute to check the attribute type and normalize the string 
  according to the attribute type. i.e. normalize the white space if 
  the attribute has any type other than CDATA or UNDECLARED.