Re: [wss] Issue 196: QNames

[Rich Salz <rsalz@datapower.com>]

> >I think qnames make implementation harder (they really are a layering
> >violation:), and the security/c14n intricacies are very difficult to
> >properly specify, let alone implement.
>

> I don't understand you comments, are you saying that you can't implement
> qnames ? Also can you point me to where its stated that its a "layering
> violation".

No, I can implement qnames, and have.  That's how I know they're a layering
violation. :)  I can't think of any other element or attribute content
that is affected by to element or attribute information (maybe xml:space, but
that's not quite the same).  In the Infoset view, to get the value of
a qname, you have to look at the namespace bindings that are in-scope in
the containing element.  You can't look at just "the value".
In a DOM, you can call a method but basically you have to walk up
the tree.  A SAX-based model would require the callbacks to maintain
a stack of in-scope bindings on their own.

Again, when looking at a qname you have to look at the namespace bindings
that are in-scope at the place where the qname appears.  At no other
time when looking at content do you have to know the context.  Hence,
layering violation. :)

Qnames as values are inconsistent.  For example, if myattr is a qname:
        <foo xmlns="http://www.example.org/q"; myattr="frag"/>
foo is in the default namespace, the name myattr is not in any namespace,
but frag is in the example.org namespace.  This rewrite makes it
more explicit:
        <Z:foo xmlns:Z="http://www.example.org/q"; myattr="Z:frag"/>
That's kind gross, don't you think? :)

> >The sooner we move to pure-URI the better off, and more secure, we'll all
> >be.
>
> Elaborate please.

I think the above -- and heck, the whole TAG qname document -- shows
why avoiding them makes us "better off."  As for the security implications,
Hal and Merlin have already made postings that are far better than any
I could do.  Hopefully someone will followup with links into the
archives for those postings.

        /r$
--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html