Proposed Xerces2 Requirements

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)

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)

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.

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)

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)

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)

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)