> What changes to SAX 1.0 are required to support two-part names?
Follows a summary of my views.
> 1. Concatentation
>
> Use a single Java String (or C++ wstring, etc.) to represent a
> two-part name; select a non-XML character to use as the separator.
I strongly support this.
> Advantages:
> - requires no modification to SAX 1.0
Also: it can be layered on top of existing SAX-compliant parsers
as a filter, so that parsers need not change for namespace support.
> Disadvantages:
> - places additional burden on applications
> - may produce unexpected results with applications that assume only
> traditional one-part names (especially normalisers)
Adding namespace support in a filter makes avoiding these problems
easy: if namespace interpretation is a Bad Idea for your application,
don't install it. It is applications, not parsers, that need or
don't need namespace information.
> - makes equality testing tricky
I'm not sure I understand this. Assuming that all relative URLs are
coerced to absolute form (which my current implementation regrettably
does not do), there seem to be no special issues.
> 2. New Interface
> Advantages:
> - provides easy and separate access to the URI part and the base
> part of a name
Adding a few static routines to separate a combined string into its
components adds very little space cost, though admittedly some
runtime cost.
> Disadvantages:
> - backwards-incompatible with SAX 1.0; all software would have to
> change
I think this is a very large cost indeed.
> Of course, we should finalise nothing until the namespaces spec
> becomes a recommendation.
Agreed, but experimental implementations are well worthwhile.
-- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)