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/08/26 20:20:30 UTC
[VOTE (PLEASE!)] Xerces2 Requirements 1-7
This is a call for a vote to finalize requirements 1 through 7 in
http://xml.apache.org/xerces-j/issues.html. The process for refining the
requirements will be described in
http://apache.org/xerces-j/issues-process.html.
Please read the attached proposal document 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. But 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 item 3.
----------------------------------------
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.
-----------------------------------------------------
-Ed Staub
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-7
Posted by James Duncan Davidson <du...@x180.com>.
on 8/27/00 2:50 PM, Curt Arnold at CurtA@techie.com wrote:
>> 1: The code shall be maintainable and simple to read.
> +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?
I got 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
readible 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.
.duncan
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-7
Posted by Curt Arnold <Cu...@techie.com>.
> 1: The code shall be maintainable and simple to read.
+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?
> 2: The parser should have a competitive memory footprint (competitive
> against the other Java based parsers out there).
+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.
> 3: The parser shall be designed so as to allow deployment of minimal
> subsets suitable for low-end, memory-constrained applications.
+1. If this type of surgery is possible, then it should help
requirement 2 since loading unused classes could be avoided.
> 6: [Vote to REMOVE this item.] The parser should have the smallest possible
> distribution (JAR) size.
+1 to remove. Tools could provide a more substantial shrinkage of the
JAR's than we could by trying to optimize the JAR size through specific
coding practices.
> 7: The design of the parser should be documented, with diagrams where they
> are more expressive than text.
+0.
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-7
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: Ed Staub
To: xerces-j-dev
Sent: Saturday, August 26, 2000 11:20 AM
Subject: [VOTE (PLEASE!)] Xerces2 Requirements 1-7
This is a call for a vote to finalize requirements 1 through 7 in
http://xml.apache.org/xerces-j/issues.html. The process for refining the
requirements will be described in
http://apache.org/xerces-j/issues-process.html.
Please read the attached proposal document 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. But 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 item 3.
----------------------------------------
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
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.
+1
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.
+1
7: The design of the parser should be documented, with diagrams where they
are more expressive than text.
+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-7
Posted by "Christophe D. Laprun" <ch...@nist.gov>.
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 provided 3 is accepted.
> 7: The design of the parser should be documented, with diagrams where they
> are more expressive than text.
+1
--
Christophe Laprun [Ingenieur ISIMA, France / Guest researcher @NIST]
web: http://www.nist.gov/speech/staff/laprunch.htm
email: chris.laprun@nist.gov
phone: (301) 975 3191 fax: (301) 670 0939
--
The universe seems neither benign nor hostile, merely indifferent -
Sagan
Re: [VOTE (PLEASE!)] Xerces2 Requirements 1-7
Posted by James Duncan Davidson <du...@x180.com>.
on 8/26/00 11:20 AM, Ed Staub at estaub@mediaone.net 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
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.
+1, given #3
7: The design of the parser should be documented, with diagrams where they
are more expressive than text.
+1
.duncan