Thanks, Eric & Duncan.

Ted Leung volunteered to work on this with me, and he's a committer.
But he's going on vacation, so giving me rights probably makes sense, at least for the time being.

I'm collating together a (hopefully) better list, with quotes and hrefs back to the mail archive.

Here's an excerpt, for review of structure.  We should have something real checked in tomorrow.


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

Each requirement has a number. The numbers are not in any useful order, but will remain stable for reference.  Underneath the number is a "hardness" and "status".

Possible "hardness" values are:
hard - Xerces 2 must and shall meet this requirement
soft - Xerces 2 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
- 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

An example entry:


The parser shall be faster than the speed of light.

"Parser output must occur before parser input..."  [spinnaker] Announce James Duncan Davidson (Sat Jul 08 2000 - 07:31:16 MEST)

  • "Transluminal parsing speeds could cause a rip in the space-time continuum..."  Re: [spinnaker] Announce Stefano Mazzocchi (Sun Jul 09 2000 - 17:36:18 MEST)

  • -Ed

    -----Original Message-----
    From: James Duncan Davidson []
    Sent: Friday, July 14, 2000 12:39 AM
    Subject: Re: XRI requirements

    on 7/12/00 10:25 AM, Eric Ye at wrote:

    > Thanks, Ed, for compiling all this requirements.  why can't you be the
    > person to continue doing this job? I don't see any problems.

    In fact if the problem is that he doesn't have commit access, let's take
    care of that -- if he's willing to keep the requirements and further design
    docs together (granted, everyone should work on them, but.. It's nice to
    have a point person as long as they are willing) -- then I'd propose he be a


    In case of troubles, e-mail:
    To unsubscribe, e-mail:
    For additional commands, e-mail: