Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Message-ID: <011e01bfec61$0b9f8610$0500a8c0@snark>
Reply-To: "Ted Leung" <twleung@sauria.com>
From: "Ted Leung" <twleung@sauria.com>
To: <general@xml.apache.org>
Cc: <estaub@mediaone.net>
References: <NBBBJCEHCKPNBDADJHGLKECICPAA.estaub@mediaone.net>
Subject: Re: XRI requirements
Date: Wed, 12 Jul 2000 17:25:56 -0700
Organization: Sauria Associates
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I'm a little behind on the mail, but I'd be happy to do this along with Ed.
I do think it is important for one of the Xerces comitters to work on this,
because I think that the requirements list should go in the repository.


----- Original Message -----
From: "Ed Staub" <estaub@mediaone.net>
To: <general@xml.apache.org>
Sent: Tuesday, July 11, 2000 9:03 PM
Subject: XRI requirements


> Here's a quick copy-and-paste list of the proposed
> XRI/Spinnaker/Xerces-2/X2/XRay requirements which have been discussed by
> various people over the last few days.  (Ok, I just threw in "X2" and
> "XRay"!;)  I did some light editing for clarity.  I probably missed a few!
>
> If folks would like me to do more with the proposed requirements list,
> please let me know and I'll propose some procedures and (better!)
> formatting.  But I suspect that it may be desirable to have a more
> well-known and experienced person recording the proposed requirements.
It's
> clearly a sensitive area where a person widely believed to be impartial
> would be very valuable.
>
> Regardless... what's missing?
>
> -Ed Staub
>
>
> FEATURES and STANDARDS COMPLIANCE
> ---------------------------------
>
> Validating XML 1.0 support
>
> Namespace support
>
> SAX2 support
>
> DOM Level 2 support
>
> XML Schema support
>
> XPath support
>
> XInclude support
>
> Write validation of a DOM tree or revalidation
>
> Grammar access for both DTD and Schema.
>
> Document-order indexes or API as a DOM extension.
>
> [optional] isWhite() method as a DOM extensions (pure telling of
> whether or not the text contains non-whitespace), for performance reasons.
>
> Serialization support, as is currently in Assaf's classes.
>
> PERFORMANCE
> -----------
>
> No significant speed penalty for unused features, notably validation.
>
> Best-of-breed performance across all JIT's (not just Hotspot).
>
> Grammar caching, pre-compiled grammar can be cached to validate instance
> documents over and over again without re-reading the DTD and Schema file
or
> even compile it.
>
> A configurable parser, in line with the requirements of Modularity and
> pluggable Validator somebody posted before.  Not only should the validator
> be pluggable, but also if there is a need for a parser without validation
at
> all, there should be some parser configuration which is really lightweight
> and just scans, checks well-formedness, and generates SAX2 events.  Or
even
> fancier, a brand new functional module can be plugged in BETWEEN
components
> as long as it implements certain interfaces.  [Eric Ye]
>
> Mid to upper range validation performance across all JVMs.
>
> Read-only, memory conservative, high performance DOM subset (for Xalan et
> al)
>
> Parsing in chunks [Scott Boag]
>
> A reasonable core (fast!) upon which to layer JDOM [Brett M.]
>
> Some sort of weak reference, where nodes could be released if not
> referenced, and then rebuilt if requested.  For performance and memory
> footprint.
>
> 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.
>
> 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?
>
> Smallest possible size. This means small distribution size (JAR
> file) and small memory footprint.
>
>
> OTHER QUALITIES
> ----------------
>
> Clarity of design and code sufficient to encourage wide participation.
> Code should always be readable and maintainable.
>
> Design portable to C++ (or elsewhere)
>
> More documentation on the Apache web site not only for users but for
> DEVELOPERs.
>
> Testcases for both conformance and benchmarking.
>
>
> ===============================
>
> NOMINAL NON-REQUIREMENTS:
>
> Someone stated, without dissent (yet!), that these do not need to be
> supported:
>
> SAX 1 support
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
>
>