ModSAX (SAX 1.1) Proposal (fwd)

[Dan Brickley]

---------- Forwarded message ----------
Date: Wed, 17 Feb 1999 14:33:36 +0000 (GMT)
From: Dan Brickley <Daniel.Brickley at bristol.ac.uk>
To: David Megginson <david at megginson.com>
Cc: daniel.brickley at bristol.ac.uk
Subject: Re: ModSAX (SAX 1.1) Proposal


David,

Here's a small proposal:
 
>     public abstract void setFeature (String featureID, boolean state)

becomes public abstract void setFeature (URI featureID, boolean state)

(or leave as String but with understanding that the datatype of
featureID is anything that's a legal Web URI)

So instead of "org.xml.sax.myfeature" we'd pass in tokens such as
"urn:sax-features:myfeature", "http://sax.org/features/myfeature",
"uuid:434234-2342342-23423423" or whatever. Anything that is a 
legal URI as per the URI RFC.

Whether these (ever) dereference to anything is a separate issue. I'm
assuming that you'll need a URI class for namespace handling anyway (or
does Java 2.0 have this alongside the Java class 'URL'?) so I don't
think I'm proposing bloat.

Justification:
	setFeature needs to be passed an identifying string that uniquely picks
	out some property. Rather than go with the pseudo-uri's in Java, it
	would be more in the spirit of XML and Web to use URIs. Using URIs is
	also more friendly towards non-Java implementations of the SAX API.

What do you think? It buys you management of the space of featureID
names, at cost of inevitable arguments about what you'll get if you
de-reference the URI. If not, what should be said about legal featureID
values?

Dan

On Mon, 15 Feb 1999, David Megginson wrote:

> Love it or hate it, here goes...
> 
> I propose that SAX 1.1 (aka ModSAX) add the following three core
> classes and interfaces to SAX 1.0 in the org.xml.sax package:
> 
> 
>   public interface ModParser extends Parser
>   {
>     public abstract void setFeature (String featureID, boolean state)
>       throws SAXNotSupportedException;
> 
>     public abstract void setHandler (String handlerID, ModHandler handler)
>       throws SAXNotSupportedException;
>   }
> 
> 
>   public interface ModHandler
>   {
>     // yup, it's empty...
>   }
> 
> 
>   public class SAXNotSupportedException extends SAXException
>   {
>     // yup, it's empty...
>   }
> 
> 
> I'm going to disappear now until Wednesday, so I'll let everyone chew
> on these for a while until I have time to offer explanations and
> arguments later this week.  
> 
> No, I haven't forgotten namespaces, or DTD information, or lexical
> information, or anything else.
> 
> 
> All the best,
> 
> 
> David
> 
> -- 
> David Megginson                 david at megginson.com
>            http://www.megginson.com/
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
> 
> 



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)