xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Snell" <jsn...@lemoorenet.com>
Subject RE: XRI requirements
Date Wed, 12 Jul 2000 05:25:50 GMT
I must appologize if this suggestion has already been made (I have to admit
that I haven't been following the discussion as closely as I should be), but
I think it would be cool for the parser to have support for loading and
validating only certain requested portions of a document -- a useful feature
when dealing with large xml databases, for example.

- James

-----Original Message-----
From: Jeffrey Rodriguez [mailto:jeffreyr_97@hotmail.com]
Sent: Tuesday, July 11, 2000 10:01 PM
To: xerces-j-dev@xml.apache.org; general@xml.apache.org
Subject: Re: XRI requirements


I would like to add to the list of requirements the following:

Grammar Caching

This would allow the parser to be set for server applications
where we have small message that need to be validated by a
parser and we do not want to reset the Grammar internal
representation every time that we get a new message.

We currently create a Grammar internal representation of
the XML Grammar that we are using ( DTD, Schema, or whatever
else will ever be defined a Grammar to describe XML) we parse
the small message and then we throw away the internal Grammar
representation until the next message comes.

With this feature, we could cache the Grammar(s) either
programmatically or as they are created for the first time.

The next time a cached DTD is found we reuse it so we do not
have to pay the penalty of creating a new Grammar.

Of fast server application that parser and try to validate
documents this would be a performance winner.

Of course all this within the confines of our pluggable architecture
so small barebone parsers don't have to validate, cache or deal
with Grammar only with basic well formdness check.

In the Server side the same parser configure to validate with
could deal with validation in an efficient way.

                Jeffrey Rodriguez
                IBM Silicon Valley

>From: "Ed Staub" <estaub@mediaone.net>
>Reply-To: general@xml.apache.org
>To: <general@xml.apache.org>
>Subject: XRI requirements
>Date: Wed, 12 Jul 2000 00:03:53 -0400
>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.
>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
>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
>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

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

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

View raw message