Lists Home |
Date Index |
- From: David Rosenborg <David.Rosenborg@xsse.se>
- To: XML Dev <email@example.com>
- Date: Thu, 13 Aug 1998 09:58:58 +0100
John Cowan wrote:
> David Rosenborg wrote:
> > Is it really necessary for the parser to deal with namespaces at
> > all (if we don't consider namespace aware validation for the moment)?
> Depends what you think "the parser" is. My design was for something
> that a parser could implement if it wanted to, but could also be
> layered over a ns-blind parser.
Yes, sorry, my question was irrelevant.
Still I think that the NamespaceResolver should not be part of
the event. One reason, as I said, is that it could easily
live as a utility on the application side and it would then
better match the other events in style. A second, and more important
reason I think, is that as it is specified now, it introduces a
new kind of state. This state is transient just as the state of
AttributeLists. The difference is that it lives beyond the
method handling the event and is terminated at some time later.
I think this adds an unnecessary complexity to SAX.
Instead you could provide a helper interface and even an
NamespaceEnabledHandlerBase that implemented that interface
together with the namespace handler interface.
Then you could write, without worrying about namespace scope
and state at all:
class Foo extends NamespaceEnabledHandlerBase
public void startElement (String name, AttributeList attributes)
UniversalName uname = resolveElementName (name);
David.Rosenborg@xsse.se Stockholm Stock Exchange
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)