First I would like to say that I think using a seperate
namespace handler in SAX is an excellent solution.
About preserving prefixes:
That's true if the applications, processing the output of
the transformation, are also namespace aware. However, if
they are not namespace aware, like most existing validation SGML/XML
software, they may rely literally on the prefixes.
In my opinion, it would be nice to have the prefixes reported
by SAX, but that's only for convenience. I could do without it
but then I would have to write a namespace aware postprocessor
that maps the URIs back to the expected prefixes, and throw it
away when the subsequent applications also get namespace aware.
About namespace resolver:
Is it really necessary for the parser to deal with namespaces at
all (if we don't consider namespace aware validation for the moment)?
In a previous posting David Megginson outlined a layered approach
which clearly shows how simple this part of namespace processing
could be. In this model the parser may be namespace aware for
validation purposes but it does not have to for other reasons.
In my opinion, having a namespace resolver in SAX is an overkill.
I'm not saying it wouldn't be useful, just that it shouldn't be
part of the SAX interface. I think it would be sufficient if
the start namespace scope method was just
startNamespaceScope (String prefix, String URI)
and then the application/SAX Filter would have to maintain
a stack of namespaces just as a typical SAX application
keeps a stack of open elements if it is building a tree.
A namespace resolver could be part of the helper classes though.
Also I think the startNamespaceScope events should occur
before the corresponding startElement event since the element
is itself inside the scope it declares.
</David>
______________________________________________________________________
David.Rosenborg@xsse.se Stockholm Stock Exchange