[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SAX2 ... missing features?
- From: Michael Brennan <Michael_Brennan@allegis.com>
- To: 'Jonathan Borden' <jborden@mediaone.net>,'David Brownell' <david-b@pacbell.net>, xml-dev@lists.xml.org
- Date: Fri, 13 Jul 2001 15:11:57 -0700
Sort of. My proposal was inspired by the API at http://www.rddl.org/docs.
The problem, though, is how to get a parser/validator that does not support
RDDL to use RDDL. The API mentioned is perfectly suited to parsing an RDDL
document (and many thanks for that code, BTW), but doesn't solve the problem
of getting a parser/validator to use it.
For instance, Xerces until recently relied exclusively upon the
"schemaLocation" attribute on the root element to associate schema instances
with namespaces. There was no other API exposed publicly to let the
developer accomplish this. Even worse, the schema validator is not
implemented as a SAX filter, so there is no way to hook into the stream and
add that attribute. The most recent release added a SAX property that lets
you programmatically set the equivalent of the "schemaLocation" attribute,
but that still means you have to identify all of the possible schemas used
before having even looked at the content of the XML document you are dealing
with.
Microsoft's XML SDK improves upon this by publicly exposing the API to it's
schema cache. You can programmatically add schemas to the schema cache.
That's a step forward, in my mind, but I'd still prefer a mechanism by which
you can supply your own resolver that resolves a schema reference when it is
needed, rather than having to identify all possible schemas used in advance.
Also, both the Xerces and Microsoft approaches presume a particular schema
dialect.
What I'd like to see:
* Validators implemented as SAX filters, rather than embedded in a black-box
fashion in the parser.
* A way to register a resource resolver with such a filter so that it asks
your resolver to locate the relevant schema.
* A SAX property for setting a handler (similar to LexicalHandler) for
capturing relevant PSVI info (I'm interested in knowing the datatypes of
attribute and element content, where relevant).
For the second item above, if there were such an interface and SAX property
defined, I could see an implementation based upon the API at
http://www.rddl.org/docs as very useful. Combine that with an EntityResolver
(probably using SOCAT or XML Catalog -- I've been toying with the ArborText
classes for this) so you can have a local instance of the RDDL document (or
even create your own if the owner of the namespace did not do so), and you
have the ideal solution, IMHO.
Does this seem on the right track, or is the better approach I'm missing?
(Or for that matter, is there work going on for available parsers,
validators, and/or editors that I'm unaware of to add RDDL support?)
> -----Original Message-----
> From: Jonathan Borden [mailto:jborden@mediaone.net]
> Sent: Friday, July 13, 2001 3:29 AM
> To: Michael Brennan; 'David Brownell'; xml-dev@lists.xml.org
> Subject: RE: SAX2 ... missing features?
>
>
> Michael Brennan wrote:
> >
> >
> > 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.
> >
>
> Does the API at http://www.rddl.org/docs fit the bill?
> Particularly note the
> RDDLFilter (a SAX2 filter) and RDDLURL classes and the
> Namespace interface.
>
> -Jonathan
>