You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Ed Staub <es...@mediaone.net> on 2000/09/07 17:24:27 UTC
[VOTE (PLEASE!)] Xerces2 Requirements 1-29
The last cycle of voting (on items 1 through 7), begun two weeks ago, did
not reach a consensus.
Only two known committers voted (Ted and Duncan). If anyone else who voted
(Curt, Mikael, Christophe) is a committer, my apologies; I couldn't find
anyone who knew how to get a definitive list. Please let me know!
I could push the vote through with my own committer vote, but I don't think
it's appropriate for me to do so, since I'm already heavily influencing the
process.
I will leave the vote open for another week; if there aren't any more votes
then I'll give up on this effort and find other ways to waste my time. I
can only presume that other folks (especially at IBM) are unhappy with this
process and unwilling to participate; there certainly was a lot of interest
in the issues back in July!
The original proposals are re-sent in the attachment
(ResolveX2_issues_1to7.html).
For those who have not voted, here's a voting sheet again.
----------------------------------------
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 applications.
4: [Already approved, no vote required.] The parser shall run well on all
virtual machines and shall not be optimized toward a particular virtual
machine.
5: [Already approved, no vote required.] Optimizations that interfere with
readability, modularity, or size should be shunned.
6: [Vote to REMOVE this item.] 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.
-----------------------------------------
This is a call for a vote to finalize requirements 8 through 29 (with
exceptions) in http://xml.apache.org/xerces-j/issues.html. The process for
refining the requirements is described in
http://apache.org/xerces-j/issues-process.html.
Please read the attached proposal document ("ResolveX2_issues_8to29.html")
closely.
Note that the words "shall" and "should" have precise "hardness" meanings.
"Shall" indicates a "hard" requirement which must be met. "Should"
indicates a strongly desired but "soft" goal.
In order for the requirements to truly be finalized, we need as much
participation in this refinement process as possible, especially from
committers. If only three people give +1's on an item, the consensus isn't
very meaningful.
For voting convenience, here is a summary to edit. Items which have already
been approved or are deferred are not listed; see the attachment. Please
note that you are voting on the full text of the items in the attachment,
not just the one-liners below. This applies especially to items 11 and 29.
----------------------------------------
8 [Vote to REMOVE this item.] The parser should have the
characteristics needed for it to be included in the JDK.
9 [Vote to APPROVE, with clarifying text.] The parser should be
upwardly compatible with Xerces.
11 [Vote to APPROVE, with clarifying text.] Development should be
coordinated with xerces-c.
23 [Vote to APPROVE.] No significant speed penalty should be invoked for
unused features, notably validation. When not validating, the parser...
24 [Vote to APPROVE.] The parser should provide best-of-breed
performance across all JIT's (not just Hotspot). Such performance shall not
com...
25 [Vote to APPROVE.] The parser should support grammar caching and
precompilation.
28 [Vote to APPROVE.] Xerces Native API. The parser should provide a
reasonable core API (fast!) upon which to layer other API's. Examples ...
29 [Vote to APPROVE REPLACEMENT. See attachment.] The project should
produce testcases for both conformance and benchmarking.
REPLACE WITH:
The project should specify external test suites which will be used to
evaluate conformance and performance.
-Ed Staub
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-29
Posted by Edwin Goei <Ed...@eng.sun.com>.
Ed Staub wrote:
>
> The last cycle of voting (on items 1 through 7), begun two weeks ago, did
> not reach a consensus.
Here's my vote. Sorry for the delay.
>
> 1: The code shall be maintainable and simple to read.
+1, It's important to have easily understandable code in order to get
developers to participate and I think this should be a primary goal.
> 2: The parser should have a competitive memory footprint (competitive
> against the other Java based parsers out there).
+1
> 3: The parser shall be designed so as to allow deployment of minimal
> subsets suitable for low-end, memory-constrained applications.
+1 subject to previous discussions of what low-end, memory-constrained
means. For example, devices such as PDAs should not be targeted because
it's probably not possible.
> 6: [Vote to REMOVE this item.] The parser should have the smallest possible
> distribution (JAR) size.
+1
>
> 7: The design of the parser should be documented, with diagrams where they
> are more expressive than text.
+1.
-Edwin
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-29
Posted by Eric Ye <er...@locus.apache.org>.
Ed,
Here are my votes.
_____
Eric Ye * IBM, JTC - Silicon Valley * ericye@locus.apache.org
----- Original Message -----
From: Ed Staub
To: xerces-j-dev
Sent: Thursday, September 07, 2000 8:24 AM
Subject: [VOTE (PLEASE!)] Xerces2 Requirements 1-29
----------------------------------------
1: The code shall be maintainable and simple to read.
+1, it's always desirable for any programs
2: The parser should have a competitive memory footprint (competitive
against the other Java based parsers out there).
+0, this should be merged with 3, and there is always time/space trade-off, some application may care about performance not memory footprint.
3: The parser shall be designed so as to allow deployment of minimal
subsets suitable for low-end, memory-constrained applications.
+1
6: [Vote to REMOVE this item.] The parser should have the smallest possible
distribution (JAR) size.
+1
7: The design of the parser should be documented, with diagrams where they
are more expressive than text.
+1
-----------------------------------------
8 [Vote to REMOVE this item.] The parser should have the
characteristics needed for it to be included in the JDK.
+1
9 [Vote to APPROVE, with clarifying text.] The parser should be
upwardly compatible with Xerces.
+1
11 [Vote to APPROVE, with clarifying text.] Development should be
coordinated with xerces-c.
+1
23 [Vote to APPROVE.] No significant speed penalty should be invoked for
unused features, notably validation. When not validating, the parser...
+0, depends on which type of validation, DTD should be fast, Schema, that'd be really a problem
24 [Vote to APPROVE.] The parser should provide best-of-breed
performance across all JIT's (not just Hotspot). Such performance shall not
com...
+1
25 [Vote to APPROVE.] The parser should support grammar caching and
precompilation.
+1, another +1 for grammar caching
28 [Vote to APPROVE.] Xerces Native API. The parser should provide a
reasonable core API (fast!) upon which to layer other API's. Examples ...
+1
29 [Vote to APPROVE REPLACEMENT. See attachment.] The project should
produce testcases for both conformance and benchmarking.
REPLACE WITH:
The project should specify external test suites which will be used to
evaluate conformance and performance.
+1.
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-29
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: Ed Staub
To: xerces-j-dev
Sent: Thursday, September 07, 2000 8:24 AM
Subject: [VOTE (PLEASE!)] Xerces2 Requirements 1-29
This is a call for a vote to finalize requirements 8 through 29 (with
exceptions) in http://xml.apache.org/xerces-j/issues.html. The process for
refining the requirements is described in
http://apache.org/xerces-j/issues-process.html.
Please read the attached proposal document ("ResolveX2_issues_8to29.html")
closely.
Note that the words "shall" and "should" have precise "hardness" meanings.
"Shall" indicates a "hard" requirement which must be met. "Should"
indicates a strongly desired but "soft" goal.
In order for the requirements to truly be finalized, we need as much
participation in this refinement process as possible, especially from
committers. If only three people give +1's on an item, the consensus isn't
very meaningful.
For voting convenience, here is a summary to edit. Items which have already
been approved or are deferred are not listed; see the attachment. Please
note that you are voting on the full text of the items in the attachment,
not just the one-liners below. This applies especially to items 11 and 29.
----------------------------------------
8 [Vote to REMOVE this item.] The parser should have the
characteristics needed for it to be included in the JDK.
+1. I'm glad to see this one go. I'd like to see a future version of Xerces
go into the JDK, but we've just got too many big company politics on
this project already.
9 [Vote to APPROVE, with clarifying text.] The parser should be
upwardly compatible with Xerces.
I think that the clarifying text should read "The parser's public API should be
upwardly compatible with Xerces 1". +0
11 [Vote to APPROVE, with clarifying text.] Development should be
coordinated with xerces-c.
"Compatibility" with xerces-c resulted in sufficient nightmares for me that I
would like to vote -1. I don't care about the C/C++ parser. They can do
whatever they want. There are no standard bindings for C++ for DOM or for
SAX2. Both those API's are performance limited and the only people who
should be using the C parser are those who can't tolerate the performance
of the Java one. I don't want the coordination effort with xerces-c to slow
down Xerces2. Those are all the reasons I want to vote -1. So, before I -1
this one, someone please convince me that this isn't a stupid requirement.
23 [Vote to APPROVE.] No significant speed penalty should be invoked for
unused features, notably validation. When not validating, the parser...
This item should be reworded to include the % speed penalty. 5% has been
tossed around by a few people. I don't like it, but having a specific target is
better than "no significant speed penalty", which sounds like lawyer speak.
24 [Vote to APPROVE.] The parser should provide best-of-breed
performance across all JIT's (not just Hotspot). Such performance shall not
com...
+1.
25 [Vote to APPROVE.] The parser should support grammar caching and
precompilation.
+1
28 [Vote to APPROVE.] Xerces Native API. The parser should provide a
reasonable core API (fast!) upon which to layer other API's. Examples ...
+1
29 [Vote to APPROVE REPLACEMENT. See attachment.] The project should
produce testcases for both conformance and benchmarking.
REPLACE WITH:
The project should specify external test suites which will be used to
evaluate conformance and performance.
+1
-Ed Staub
------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-29
Posted by Assaf Arkin <ar...@intalio.com>.
Ed Staub wrote:
> ----------------------------------------
>
> 1: The code shall be maintainable and simple to read.
+1
> 2: The parser should have a competitive memory footprint (competitive
> against the other Java based parsers out there).
+1
> 3: The parser shall be designed so as to allow deployment of minimal
> subsets suitable for low-end, memory-constrained applications.
+1
> 6: [Vote to REMOVE this item.] The parser should have the smallest possible
> distribution (JAR) size.
+1
Alternative minimal footprint parsers for small devices already exist,
and this conflicts with a growing requirement list by the enterprise
users (XML Schema, XCatalog, WML, etc).
> 7: The design of the parser should be documented, with diagrams where they
> are more expressive than text.
+1
arkin
>
> -----------------------------------------
>
> This is a call for a vote to finalize requirements 8 through 29 (with
> exceptions) in http://xml.apache.org/xerces-j/issues.html. The process for
> refining the requirements is described in
> http://apache.org/xerces-j/issues-process.html.
>
> Please read the attached proposal document ("ResolveX2_issues_8to29.html")
> closely.
>
> Note that the words "shall" and "should" have precise "hardness" meanings.
> "Shall" indicates a "hard" requirement which must be met. "Should"
> indicates a strongly desired but "soft" goal.
>
> In order for the requirements to truly be finalized, we need as much
> participation in this refinement process as possible, especially from
> committers. If only three people give +1's on an item, the consensus isn't
> very meaningful.
>
> For voting convenience, here is a summary to edit. Items which have already
> been approved or are deferred are not listed; see the attachment. Please
> note that you are voting on the full text of the items in the attachment,
> not just the one-liners below. This applies especially to items 11 and 29.
>
> ----------------------------------------
>
> 8 [Vote to REMOVE this item.] The parser should have the
> characteristics needed for it to be included in the JDK.
>
> 9 [Vote to APPROVE, with clarifying text.] The parser should be
> upwardly compatible with Xerces.
>
> 11 [Vote to APPROVE, with clarifying text.] Development should be
> coordinated with xerces-c.
>
> 23 [Vote to APPROVE.] No significant speed penalty should be invoked for
> unused features, notably validation. When not validating, the parser...
>
> 24 [Vote to APPROVE.] The parser should provide best-of-breed
> performance across all JIT's (not just Hotspot). Such performance shall not
> com...
>
> 25 [Vote to APPROVE.] The parser should support grammar caching and
> precompilation.
>
> 28 [Vote to APPROVE.] Xerces Native API. The parser should provide a
> reasonable core API (fast!) upon which to layer other API's. Examples ...
>
> 29 [Vote to APPROVE REPLACEMENT. See attachment.] The project should
> produce testcases for both conformance and benchmarking.
> REPLACE WITH:
> The project should specify external test suites which will be used to
> evaluate conformance and performance.
>
> -Ed Staub
>
> ------------------------------------------------------------------------
> Name: ResolveX2_issues_8to29.html
> ResolveX2_issues_8to29.html Type: Hypertext Markup Language (text/html)
> Encoding: quoted-printable
>
> Name: ResolveX2_issues_1to7.html
> ResolveX2_issues_1to7.html Type: Hypertext Markup Language (text/html)
> Encoding: quoted-printable
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
--
----------------------------------------------------------------------
Assaf Arkin www.intalio.com
CTO, Intalio Inc. www.exolab.org
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-29
Posted by James Duncan Davidson <du...@x180.com>.
on 9/7/00 8:24 AM, Ed Staub at estaub@mediaone.net wrote:
> The last cycle of voting (on items 1 through 7), begun two weeks ago, did not
> reach a consensus.
That worked.. Lots of people out of the woodwork.. :)
Ok, here are my votes for 8-29
> 8 [Vote to REMOVE this item.] The parser should have the characteristics
> needed for it to be included in the JDK.
+1 -- the folks working on seeing if it can go in the JDK should make sure
that the set of req's fit that, just as the people looking to ship it as
IBMXML4J are hopefully making sure that it meets their reqs. This doesn't
need to be explicit.
> 9 [Vote to APPROVE, with clarifying text.] The parser should be upwardly
> compatible with Xerces.
+0 -- as it doesn't say "shall" and it's soft, I won't -1. Of course my
stance is that its the public API set (SAX, DOM, etc) that should be
maintained.. Everything else should be free to be moved on from.
> 11 [Vote to APPROVE, with clarifying text.] Development should be
> coordinated with xerces-c.
+0 -- as it doesn't say "shall" and it's soft, I won't -1. Apples and
Oranges in my mind and I think that the Xerces-C folks will diverge on their
own. Of course we should attempt to make things feature equive between the
codebases, but not the codebases.
> 23 [Vote to APPROVE.] No significant speed penalty should be invoked for
> unused features, notably validation. When not validating, the parser...
+1
> 24 [Vote to APPROVE.] The parser should provide best-of-breed performance
> across all JIT's (not just Hotspot). Such performance shall not com...
+1
> 25 [Vote to APPROVE.] The parser should support grammar caching and
> precompilation.
+1
> 28 [Vote to APPROVE.] Xerces Native API. The parser should provide a
> reasonable core API (fast!) upon which to layer other API's. Examples ...
+1111
> 29 [Vote to APPROVE REPLACEMENT. See attachment.] The project should
> produce testcases for both conformance and benchmarking. REPLACE WITH: The
> project should specify external test suites which will be used to evaluate
> conformance and performance.
+1
.duncan