RE: SAX2 ... missing features?

[Michael Brennan <Michael_Brennan@allegis.com>]

It would be nice to see a standardized interface for supplying an object
responsible for locating resources associated with a namespace. This is
badly needed for parsers that support schema validation. Currently, parsers
I've looked at either rely upon the "schemaLocation" attribute, or employ
entirely proprietary interfaces requiring the writing of non-portable code.
Xerces just added the ability to provide your own mapping, but in a manner
that duplicates the "schemaLocation" attribute. This is not a scalable
approach. Can you imagine if instead of having an EntityResolver interface,
we had to supply a list or URI pairs to the parser in advance of parsing?

I'd like to see a standard SAX extension for a resource resolver. It could
perhaps take some cues from RDDL -- i.e. allow the parser to ask for
resources related to a namespace URI based on a nature, purpose, or both.
Perhaps something like:

 public interface ResourceResolver
 {
    public InputSource resolveResourceByNature(
        String namespaceURI, String nature );
    public InputSource resolveResourceByPurpose( 
        String namespaceURI, String nature );
    public InputSource resolveResource( 
        String namespaceURI, String nature, String purpose );
  }

This addresses the problem while remaining extensible (i.e. it doesn't tie
the API to a specific purpose or schema grammar).

I'd really, really like to see parsers supporting a portable, scalable API
for this sort of thing.

> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Monday, July 09, 2001 2:23 PM
> To: xml-dev@lists.xml.org
> Subject: SAX2 ... missing features?
> 
> 
> SAX2 has been out for a while, and I'm curious what folks'
> pet peeves are.  Please share!  I'd hope that some of these
> could turn into (backwards compatible) updates.
> 
> Here's a random list that might seed some discussions.
> 
> - features/properties
> 
>     * Parser name and version can be useful when
>        troubleshooting ... a string property?
> 
> - more infoset items
> 
>     * xml version unavailable.  Fix might be providing
>        a string property, logically augmenting the locator's
>        information about any given entity.  If blueberry,
>        then different core rules may apply...
> 
>     * text encoding unavailable.  Similar to version; apps
>        need this to know if "Unicode Normalization Form
>        C" must be applied in some cases (C14N, current
>        DOM L3 draft for saving).
> 
>     * standalone flag unavailable.  Could also be a
>        string property, but unrelated to locator info.
>        (Probably affects XML generation most.)
> 
>     * Attribute "specified" flag is omitted.  (Likewise,
>        mostly affects XML generation -- or DOM.)
> 
> - conformance
> 
>     * NamespaceSupport.declarePrefix() should likely
>       report some kind of error for a relative URI (no "://")
> 
> I'm also tempted to put "no utility library" on that list.
> Stuff like an XML writer gets used by most folk that
> focus on SAX, and something to efficiently test whether
> characters are legal parts of XML (1.0 :) names.  And
> there's lots of other stuff which, were it more generally
> available, would make it easier for folk to leverage SAX.
> 
> Comments?
> 
> - Dave
> 
> 
> 
> 
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org
>