[XML-SIG] SAX Namespaces

[Ken MacLeod]

<tpassin@home.com> writes:

> Paul Prescod said - (does this look like a put-up-or-shut-up???  :) )
> 
> > I'm not sure what you are suggesting concretely. You and I agree
> > that most of the current applications allow you to work based on
> > the rawname or the URI/localname pair. Therefore we need three
> > pieces of information. How do you suggest we should represent
> > them?

> The DOM level 2 NS-specific calls want to see URI and localname.  We
> should use a tuple (uri,localname).  Some of the NS calls also want
> to see a prefix or a rawname (same as 'qualified name', as I
> understand it), and sometimes both.  I propose that the rawname
> always be supplied, and the prefix always be computed.  This seems
> to fit best the pattern of the DOM calls, and also using DOM 1 calls
> with no namespaces.  Or in other words, I'm guessing :) the prefix
> won't be needed as often as the rawname, so it is just as well to
> compute it if needed.
> 
> So the name could be
> 
> A) A tuple, ((uri,localname),rawname),
> 
> B) an object with attributes for each of these things, or
> 
> C) a dictionary.
> 
> We've heard support for just about everything.  An object could be
> attractive, since it could have methods to do all the mix-and match we want.
> But it seems to me that the tuple - approach A - is the simplest.
> 
> The main thing is to agree whether the prefix (or rawname, or neither)
> should be computed rather than included explicitly in the name.  From the
> point of view of no redundance, the prefix should be included and the
> rawname should be omitted.  But I think, as Paul suggested, that the
> usefulness of the rawname says that it should be included instead of the
> prefix.
> 
> So my vote is for A).

Another option that hasn't been mentioned in a while is for SAX events
to pass DOM objects (a la EventDOM [nee EasySAX] and pulldom).  DOM
objects have a very natural place for all the parts of the namespace
issue (raw name/qname, namespace URI, localname) for both elements and
attributes.

I would vote for the DOM-passing interface as the primary promoted
interface, as long as I knew there were "performance interfaces"
available for those that realy need the performance.

  -- Ken