xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Staub" <est...@mediaone.net>
Subject XRI requirements
Date Wed, 12 Jul 2000 04:03:53 GMT
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


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.


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

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

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.


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

Testcases for both conformance and benchmarking.



Someone stated, without dissent (yet!), that these do not need to be

	SAX 1 support

View raw message