# Proposed Xerces2 Requirements

#### Date: 15 September 2000
Editors: Ed Staub Ted Leung

## Schema

Proposed requirements are organized into categories. Some requirements occur in more than one category in the future.

Each requirement has a number. Underneath the number is a "hardness" and "status".

Possible "hardness" values are:
  hard - Xerces2 must and shall meet this requirement
  soft - Xerces2 should meet this requirement, but it may be dropped because of conflicting requirements or time pressures
Possible "status" values are:
  approved - there appears to be a clear consensus
  tooQuiet - there may be a consensus, but there hasn't been enough input to be sure
  hardnessConflict - there is conflict over whether this is a hard or soft requirement
  vetoConflict - there is a conflict over whether this proposed requirement is a requirement at all
  rejected - the proposed requirement appears to be dead
  unevaluated - editor hasn't finished reviewing input

## Requirements by Number

1 The code shall be maintainable and simple to read.
2 The parser should have a competitive memory footprint (competitive against the other Java based parsers out there).
3 The parser shall be designed so as to allow deployment of minimal subsets suitable for low-end, memory-constrained appli...
4 The parser shall run well on all virutal machines and shall not be optimized toward a particular virtual machine.
5 Optimizations that interfere with readability, modularity, or size should be shunned.
6 The parser should have the smallest possible distribution (JAR) size.
7 The design of the parser should be documented, with diagrams where they are more expressive than text.
8 The parser should have the characteristics needed for it to be included in the JDK.
9 The parser should be upwardly compatible with Xerces.
10 The parser shall be cleanly modular.
11 Development should be coordinated with xerces-c.
12 The parser shall support SAX2.
13a Read-only, memory conservative, high performance DOM subset. In some ways, this is optional, since the alternative...
13b parse-next function, with added control over buffer size.
13c Some sort of way to tell if a SAX char buffer is going to be overwritten, so data doesn't have to be copied until ...
13d Serialization support, as is currently in Assaf's classes.
13e Schema data-type support, which will be needed for XSLT2, and Xalan 2.0 extensions.
13f Small core footprint for standalone, compiled stylesheet capability, for use on small devices. This would need to ...
14 The parser shall validate XML 1.0.
15 The parser shall support namespaces.
16 The parser shall support DOM Level 2.
18 The parser shall support XML Schema.
19 The parser shall support XPath.
20 The parser should support XInclude.
21 The parser should support write validation of a DOM tree or revalidation.
22 The parser shall support grammar access for both DTD and Schema.
23 No significant speed penalty should be invoked for unused features, notably validation. When not validating, the parser...
24 The parser should provide best-of-breed performance across all JIT's (not just Hotspot). Such performance shall not com...
25 The parser should support grammar caching and precompilation.
28 Xerces Native API. The parser should provide a reasonable core API (fast!) upon which to layer other API's. Examples ...
29 The project should produce testcases for both conformance and benchmarking.
30 The parse shall support SAX 1
31 The core parser should not directly support any tree model.
32 The parser shall support Java 1.1
33 The parser should support loading and validating only certainrequested portions of a document -- a useful feature when...
34 The parser shall support the XML Information Set.
35 The parser should support pull model parsing.
37 The DOM should emit events to interested listeners when changes are made to the DOM
38 The parser should support RELAX .
39 The parser should allow for automatic detection of compressed/encrypted documents.

## Requirement Categories

Architecture
Standards
Features
Memory
Speed
Quality
Other

## Requirements by Category

### Architecture

3. hard approved | The parser shall be designed so as to allow deployment of minimal subsets suitable for low-end, memory-constrained applications The build process shall create both: a .jar file containing all standard components of Xerces (xerces.jar). a set of .jar files which together contain everything in xerces.jar, broken into the following components: xerces kernel, which supports the “internal APIs” and SAX support DOM support Validation support other components of large size which can be easily factored and for which there is a significant audience who will benefit from not including them in a deployment. See also: 2 See also: 13 Voted on from 26-Aug-00 to 15-Sept-00. Votes: Curt Arnold : +1 If this type of surgery is possible, then it should help requirement 2 since loading unused classes could be avoided. Chris Laprun : +1 Ted Leung : +1 James Duncan Davidson : +1 Mikael Helbo Kjaer : +1 Jeffrey Rodriguez : +1 Arnaud Le Hors : +1 Assaf Arkin : +1 Eric Ye : +1 Edwin Goei : +1 References "It should be possible to build a parser as a set of Jar files so that a smaller parser can be assembled which fits the need of a particular implementation. For example, in TV sets do you really need validation?" [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST) "Where I am now we use XML as a wire format, so the data volume is small, and parsing takes place on the client (the customer's e-commerce environment) and on the server. Small footprint (memory *and* disk) are much more important in this context than speed or even validation. " Re: [spinnaker] Announce Rod McChesney (Wed Jul 12 2000 - 01:32:31 MEST) "... many applications could benefit ..." Re: [spinnaker] Announce Rod McChesney (Wed Jul 12 2000 - 01:32:31 MEST) ""small-but-performant-ambitious" devices vs. "as-small-and-cheap-as-possible" devices" RE: REDOM Design discussion. Paulo Gaspar (Sat Jul 15 2000 - 15:33:49 MEST) "I [am] a proponent [of support for] "small-but-perfrormant-ambitious", not "as-small-and-cheap-as-possible" [devices] " Re: REDOM Design discussion. James Duncan Davidson (Tue Jul 18 2000 - 00:28:02 MEST)

### Standards

12. hard approved | The parser shall support SAX2. See also: 13 References Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: parser-next-gen goals, plan, and requirements Arnaud Le Hors (Wed Jul 12 2000 - 02:49:04 MEST)
14. hard approved | The parser shall validate XML 1.0. References Re: parser-next-gen goals, plan, and requirements Arnaud Le Hors (Wed Jul 12 2000 - 02:49:04 MEST)
15. hard approved | The parser shall support namespaces. References Re: parser-next-gen goals, plan, and requirements Arnaud Le Hors (Wed Jul 12 2000 - 02:49:04 MEST)
18. hard approved | The parser shall support XML Schema. References Re: parser-next-gen goals, plan, and requirements Eric Ye (Wed Jul 12 2000 - 02:48:42 MEST) Re: parser-next-gen goals, plan, and requirements Arnaud Le Hors (Wed Jul 12 2000 - 02:49:04 MEST)
19. hard approved | The parser shall support XPath. References Re: parser-next-gen goals, plan, and requirements Donald Ball (Wed Jul 12 2000 - 02:57:59 MEST) Re: parser-next-gen goals, plan, and requirements Brett McLaughlin (Wed Jul 12 2000 - 16:07:32 MEST) Re: parser-next-gen goals, plan, and requirements Eduardo Pelegri--Llopart (Wed Jul 12 2000 - 19:31:22 MEST) Re: parser-next-gen goals, plan, and requirements Jeffrey Rodriguez (Wed Jul 12 2000 - 19:38:42 MEST) Re: parser-next-gen goals, plan, and requirements Stefano Mazzocchi (Thu Jul 13 2000 - 01:11:58 MEST) Re: XRI requirements Jeffrey Rodriguez (Wed Jul 12 2000 - 09:59:50 MEST)
20. soft unevaluated | The parser should support XInclude. References "+1" Re: parser-next-gen goals, plan, and requirements Donald Ball (Wed Jul 12 2000 - 02:57:59 MEST) "+1" Re: parser-next-gen goals, plan, and requirements Stefano Mazzocchi (Wed Jul 12 2000 - 15:02:47 MEST) "+1" Re: parser-next-gen goals, plan, and requirements Jeffrey Rodriguez (Wed Jul 12 2000 - 19:38:42 MEST)
22. hard unevaluated | The parser shall support grammar access for both DTD and Schema. See also: 13 References Re: parser-next-gen goals, plan, and requirements Eric Ye (Wed Jul 12 2000 - 02:48:42 MEST)
30. hard rejected | The parse shall support SAX 1 References "-1" Re: parser-next-gen goals, plan, and requirements Brett McLaughlin (Wed Jul 12 2000 - 03:07:59 MEST) "-1" Re: parser-next-gen goals, plan, and requirements N. Sean Timm (Wed Jul 12 2000 - 05:59:47 MEST) "-1" Re: parser-next-gen goals, plan, and requirements Stefano Mazzocchi (Wed Jul 12 2000 - 15:02:47 MEST)
32. hard rejected | The parser shall support Java 1.1 References "-1" Re: parser-next-gen goals, plan, and requirements Brett McLaughlin (Wed Jul 12 2000 - 03:07:59 MEST) "-1" Re: parser-next-gen goals, plan, and requirements N. Sean Timm (Wed Jul 12 2000 - 05:59:47 MEST) "-1" Re: parser-next-gen goals, plan, and requirements Stefano Mazzocchi (Wed Jul 12 2000 - 15:02:47 MEST) "+1" Re: REDOM Design discussion. Jeffrey Rodriguez (Fri Jul 14 2000 - 18:47:28 MEST) "+-0" Re: REDOM Design discussion. James Duncan Davidson (Fri Jul 14 2000 - 19:22:19 MEST)
34. hard unevaluated | The parser shall support the XML Information Set. References "+1" Re: [Xerces2] Requirements list; 'Xerces2'?; cross-posting Arnaud Le Hors (Wed Jul 12 2000 - 20:46:38 MEST) "+1" Re: [Xerces2] Requirements list; 'Xerces2'?; cross-posting Stefano Mazzocchi (Thu Jul 13 2000 - 01:13:00 MEST)

### Features

13a. soft unevaluated | Read-only, memory conservative, high performance DOM subset. In some ways, this is optional, since the alternative is that the XSLT processor implement it's own DOM, as it does today. But it would be neat and simpler if only one DOM implementation needed to exist. a) Document-order indexes or API as a DOM extension. I know of few or no conformant XSLT processors that can do without this. b) [optional] isWhite() method as a DOM extensions (pure telling of whether or not the text contains non-whitespace), for performance reasons. c) Some sort of weak reference, where nodes could be released if not referenced, and then rebuilt if requested. For performance and memory footprint. References Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 19:59:46 MEST)
13b. soft unevaluated | parse-next function, with added control over buffer size. References Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 19:59:46 MEST)
13c. soft unevaluated | Some sort of way to tell if a SAX char buffer is going to be overwritten, so data doesn't have to be copied until this occurs. References Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 19:59:46 MEST)
13d. soft unevaluated | Serialization support, as is currently in Assaf's classes. References Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 19:59:46 MEST)
13e. soft unevaluated | Schema data-type support, which will be needed for XSLT2, and Xalan 2.0 extensions. References Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 19:59:46 MEST)
13f. soft unevaluated | Small core footprint for standalone, compiled stylesheet capability, for use on small devices. This would need to include the Serializer. I'm not sure if this should really be a separate micro-parser? References Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 19:59:46 MEST)
16. hard approved | The parser shall support DOM Level 2. References Re: parser-next-gen goals, plan, and requirements Arnaud Le Hors (Wed Jul 12 2000 - 02:49:04 MEST)
21. soft unevaluated | The parser should support write validation of a DOM tree or revalidation. References Re: parser-next-gen goals, plan, and requirements Eric Ye (Wed Jul 12 2000 - 02:48:42 MEST)
28. soft approved | Xerces Native API. The parser should provide a reasonable core API (fast!) upon which to layer other API's. Examples of such API's include SAX2, DOM, and JDOM. See also: 10 Voted on from 07-Sept-00 to 15-Sept-00. Votes: Jeffrey Rodriguez : +1 Eric Ye : +1 Curt Arnold : +1 James Duncan Davidson : +1 Ted Leung : +1 Mikael Helbo Kjaer : +1 Arnaud Le Hors : +1 References Re: parser-next-gen goals, plan, and requirements Brett McLaughlin (Wed Jul 12 2000 - 00:28:32 MEST) "JDOM is an important up and coming API that already has established a large and rapidly growing groundswell of support and in the developer community." Re: parser-next-gen goals, plan, and requirements James Duncan Davidson (Wed Jul 12 2000 - 01:15:59 MEST)
31. soft unevaluated | The core parser should not directly support any tree model. See also: 10 References "My understanding of the design, which I think is good, is that the "core" actually doesn't directly support any tree model. API Layer JDOM DOM SAX2 Core Layer Java parser code " Re: [spinnaker] Announce Arnaud Le Hors (Tue Jul 11 2000 - 03:41:05 MEST) Re: parser-next-gen goals, plan, and requirements Jason Hunter (Wed Jul 12 2000 - 07:51:22 MEST) Re: parser-next-gen goals, plan, and requirements Tim Bray (Thu Jul 13 2000 - 02:33:14 MEST) [spinnaker] Design discussion James Duncan Davidson (Mon Jul 10 2000 - 08:04:29 MEST) Re: [spinnaker] Design discussion costin@eng.sun.com (Mon Jul 10 2000 - 20:40:06 MEST) Re: [spinnaker] Design discussion Edwin Goei (Tue Jul 11 2000 - 00:48:20 MEST) Re: ?? Design discussion - xerces-design-dev new list Arnaud Le Hors (Tue Jul 11 2000 - 06:51:24 MEST) [Xerces2] What is CORE? Ed Staub (Fri Jul 14 2000 - 23:34:45 MEST) Re: [Xerces2] What is CORE? Brett McLaughlin (Fri Jul 14 2000 - 23:52:26 MEST) Re: [Xerces2] What is CORE? Arved Sandstrom (Sat Jul 15 2000 - 01:08:07 MEST)
33. soft unevaluated | The parser should support loading and validating only certainrequested portions of a document -- a useful feature when dealing with large xml databases, for example. See the W3C XML Fragement Interchange Working Draft. References RE: XRI requirements James Snell (Wed Jul 12 2000 - 07:25:50 MEST)
35. soft unevaluated | The parser should support pull model parsing. References Microsoft XML stuff Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 21:46:16 MEST) Re: Microsoft XML stuff Ted Leung (Thu Jul 13 2000 - 02:08:55 MEST) Re: Microsoft XML stuff Ted Leung (Thu Jul 13 2000 - 06:46:09 MEST) Re: Microsoft XML stuff Eric Hodges (Thu Jul 13 2000 - 09:15:49 MEST) RE: Microsoft XML stuff Scott Boag/CAM/Lotus (Thu Jul 13 2000 - 06:29:25 MEST)
37. soft unevaluated | The DOM should emit events to interested listeners when changes are made to the DOM References Re: ?? Design discussion - xerces-design-dev new list Kelly Campbell (Tue Jul 11 2000 - 03:08:57 MEST)
38. soft unevaluated | The parser should support RELAX .
39. soft unevaluated | The parser should allow for automatic detection of compressed/encrypted documents.

### Memory

2. soft approved | The parser should have a competitive memory footprint (competitive against the other Java based parsers out there). See also: 3 Voted on from 26-Aug-00 to 15-Sept-00. Votes: Curt Arnold : +1 I assume that the comparison would be some basket of scenarios, so that being efficient with large documents could offset a slightly greater initial load size. Chris Laprun : +1 Ted Leung : +1 James Duncan Davidson : +1 Mikael Helbo Kjaer : +1 Jeffrey Rodriguez : +1 Arnaud Le Hors : +1 Assaf Arkin : +1 Eric Ye : +0 Edwin Goei : +1 References "This means small distribution size (JAR file) and small memory footprint." [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST) Re: parser-next-gen goals, plan, and requirements Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 23:42:10 MEST) Re: [spinnaker] Announce Stefano Mazzocchi (Thu Jul 13 2000 - 01:52:43 MEST) Re: [spinnaker] Announce costin@eng.sun.com (Thu Jul 13 2000 - 21:46:20 MEST)
6. soft rejected | The parser should have the smallest possible distribution (JAR) size. See also: 3 Voted on from 26-Aug-00 to 15-Sept-00. Votes: Curt Arnold : +1 to remove Chris Laprun : +1 to remove Ted Leung : +1 to remove James Duncan Davidson : +1 to remove Mikael Helbo Kjaer : +1 to remove Jeffrey Rodriguez : +1 to remove Arnaud Le Hors : +1 to remove Assaf Arkin : +1 to remove Eric Ye : +1 to remove Edwin Goei : +1 to remove Ed:The votes below were votes to remove this requirement. Its concerns are addressed elsewhere. References "This means small distribution size (JAR file) and small memory footprint. " [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST) "These two requirements [small memory footprint, small jar size -ed] are in direct conflict. " Re: [spinnaker] Announce Arnaud Le Hors (Sat Jul 08 2000 - 19:56:58 MEST)

### Speed

4. hard approved | The parser shall run well on all virutal machines and shall not be optimized toward a particular virtual machine. References [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST) Re: REDOM Design discussion. Jim Driscoll (Thu Jul 13 2000 - 18:12:19 MEST) Re: REDOM Design discussion. James Duncan Davidson (Fri Jul 14 2000 - 06:38:44 MEST)
23. soft approved | No significant speed penalty should be invoked for unused features, notably validation. When not validating, the parser should run almost as fast (within 5%) as a non-validating parser. See also: 10 Voted on from 07-Sept-00 to 15-Sept-00. Votes: Jeffrey Rodriguez : 0 Eric Ye : +0 Curt Arnold : +1 James Duncan Davidson : +1 Ted Leung : +1 Mikael Helbo Kjaer : +1 Arnaud Le Hors : +1
24. soft approved | The parser should provide best-of-breed performance across all JIT's (not just Hotspot). Such performance shall not come at the expense of requirement 5. See also: 5 Voted on from 07-Sept-00 to 15-Sept-00. Votes: Jeffrey Rodriguez : +1 Eric Ye : +1 Curt Arnold : +1 James Duncan Davidson : +1 Ted Leung : +1 Mikael Helbo Kjaer : +1 Arnaud Le Hors : +1 References "-1 (on JDK 1.1)" Re: REDOM Design discussion. James Duncan Davidson (Fri Jul 14 2000 - 19:22:19 MEST) "Fast enough to not notice that a parse happened for most data (10 lines to 10K). To expand on that, when I have Ant read it's data from build.xml, I shouldn't notice. If I send a bit of form encoded XML data to a server, and then get some back, it shouldn't be appreciable considering the connection cost. " Re: [Xerces2] What is CORE? James Duncan Davidson (Sat Jul 15 2000 - 06:31:24 MEST)
25. soft approved | The parser should support grammar caching and precompilation. Voted on from 07-Sept-00 to 15-Sept-00. Votes: Jeffrey Rodriguez : +1 Eric Ye : +1 Curt Arnold : +1 James Duncan Davidson : +1 Ted Leung : +1 Mikael Helbo Kjaer : +1 Arnaud Le Hors : +1 References Re: parser-next-gen goals, plan, and requirements Eric Ye (Wed Jul 12 2000 - 02:48:42 MEST) Re: XRI requirements Jeffrey Rodriguez (Wed Jul 12 2000 - 07:01:23 MEST)

### Quality

1. hard approved | The code shall be maintainable and simple to read. See also: 5 Voted on from 26-Aug-00 to 15-Sept-00. Votes: Curt Arnold : +1 +1 on intent. But how can this be a "shall" when there is not a measure for maintainability or simplicity. Are there specific criteria that we want to establish such as the Sun's Java coding conventions or something else from the Apache world? Chris Laprun : +1 Ted Leung : +1 James Duncan Davidson : +1 I have an easy way to measure this.. Committers should only be committers if they are prepared to read the code commits. If the code commit isn't readable to somebody and they throw a flag, then it probably fails the test. For example, my criteria on such code would be that I can understand it. If everybody's criteria is this, then it works. Mikael Helbo Kjaer : +1 Jeffrey Rodriguez : +1 Arnaud Le Hors : +1 Assaf Arkin : +1 Eric Ye : +1 Edwin Goei : +1 References " Above all, this is the primary goal for any openly developed project as without the ability to read the code, it's impossible for people to contribute and get involved." [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST) Re: [spinnaker] Announce Edwin Goei (Mon Jul 10 2000 - 23:18:54 MEST) "[current code too complex, scares off users]" Re: [spinnaker] Announce Brett McLaughlin (Tue Jul 11 2000 - 22:17:03 MEST) "I don't think I am [willing to trade off some performance for clearly written code]. Performance is too damned important in the XML world" Re: [spinnaker] Announce Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 00:25:18 MEST) "You're not going to get a diverse developer community built around code that is too damned hard to read... " Re: [spinnaker] Announce James Duncan Davidson (Wed Jul 12 2000 - 01:11:58 MEST) Re: [spinnaker] Announce Scott Boag/CAM/Lotus (Wed Jul 12 2000 - 23:44:52 MEST)
5. soft approved | Optimizations that interfere with readability, modularity, or size should be shunned. See also: 1 References [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST)
7. soft approved | The design of the parser should be documented, with diagrams where they are more expressive than text. Voted on from 26-Aug-00 to 15-Sept-00. Votes: Curt Arnold : +0 Chris Laprun : +1 Ted Leung : +1 James Duncan Davidson : +1 Mikael Helbo Kjaer : +1 Jeffrey Rodriguez : +1 Arnaud Le Hors : +1 Assaf Arkin : +1 Eric Ye : +1 Edwin Goei : +1 References "... would benefit greatly from requirements and design documentation; most especially some diagrams. I find that a dozen or so good diagrams often do a better job of conveying the design and, perhaps more importantly, the design approach or philosophy, than written documents. " design docs and diagrams [was Re: [spinnaker] Announce] Randall J. Parr (Sun Jul 09 2000 - 18:43:49 MEST)
9. soft rejected | The parser should be upwardly compatible with Xerces. Voted on from 07-Sept-00 to 15-Sept-00. Votes: Jeffrey Rodriguez : 0 Eric Ye : +1 Curt Arnold : +1 James Duncan Davidson : +0 Ted Leung : 0 Mikael Helbo Kjaer : +1 Arnaud Le Hors : +1 References "Whatever happened to making things upgrade compatiable. " Re: [spinnaker] Announce MITCHELL SOJDEHEI (Mon Jul 10 2000 - 02:57:49 MEST)
10. hard approved | The parser shall be cleanly modular. References [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST) Re: [spinnaker] Announce costin@eng.sun.com (Mon Jul 10 2000 - 19:54:06 MEST) Re: [spinnaker] Announce costin@eng.sun.com (Mon Jul 10 2000 - 22:48:38 MEST) "[star vs. pipeline]" Re: [spinnaker] Announce Arnaud Le Hors (Tue Jul 11 2000 - 03:41:05 MEST)

### Other

8. soft rejected | The parser should have the characteristics needed for it to be included in the JDK. Voted on from 07-Sept-00 to 15-Sept-00. Votes: James Duncan Davidson : +1 to remove Jeffrey Rodriguez : +1 to remove Eric Ye : +1 to remove Curt Arnold : +0 Ted Leung : +1 to remove Mikael Helbo Kjaer : +1 to remove Arnaud Le Hors : +1 References [spinnaker] XML Hack Article James Duncan Davidson (Mon Jul 10 2000 - 00:47:01 MEST)
11. soft unevaluated | Development should be coordinated with xerces-c. Voted on from 07-Sept-00 to 15-Sept-00. Votes: Jeffrey Rodriguez : 0 Eric Ye : +1 Curt Arnold : +1 James Duncan Davidson : +0 Ted Leung : -1 Mikael Helbo Kjaer : -1 (non-committer) Arnaud Le Hors : +1 References "I'd also like to see this be coordinated with the xerces-c developers ... it would be nice to keep the two parsers in sync so that changes to one parser and relatively easy to implement in the other. " Re: [spinnaker] Announce Joe Polastre (Mon Jul 10 2000 - 23:05:18 MEST) "I disagree..." Re: [spinnaker] Announce James Duncan Davidson (Mon Jul 10 2000 - 23:34:54 MEST) "Java is a very different language from C++, and you need different strategies. " Re: [spinnaker] Announce Scott Boag/CAM/Lotus (Tue Jul 11 2000 - 05:25:51 MEST) "...there's much to be gained by keeping the overall architecture and design the same between the two versions. " Re: [spinnaker] Announce Andy Heninger (Tue Jul 11 2000 - 18:59:24 MEST) "[forcing deep similarity is bad]" Re: [spinnaker] Announce James Duncan Davidson (Tue Jul 11 2000 - 22:39:19 MEST) "...trying to find one design that fits both languages well will produce one design that doesn't quite fit either language. " Re: [spinnaker] Announce Eric Hodges (Wed Jul 12 2000 - 01:23:23 MEST) "Let's push for high-level designs that can accommodate any OO language..." Re: [spinnaker] Announce Arved Sandstrom (Wed Jul 12 2000 - 02:22:53 MEST) Re: [spinnaker] Announce James Duncan Davidson (Wed Jul 12 2000 - 02:55:07 MEST) Re: [spinnaker] Announce Eric Hodges (Wed Jul 12 2000 - 03:03:32 MEST)
29. soft approved | The project should produce testcases for both conformance and benchmarking. Voted on from 07-Sept-00 to 15-Sept-00. Votes: Jeffrey Rodriguez : 0 Eric Ye : +1 Curt Arnold : +1 James Duncan Davidson : +1 Ted Leung : +1 Mikael Helbo Kjaer : +1 Arnaud Le Hors : +0 References Re: parser-next-gen goals, plan, and requirements Eric Ye (Wed Jul 12 2000 - 02:48:42 MEST)