[XML-SIG] IPC7 results

[Lars Marius Garshol]

* Lars Marius Garshol
>
> I'm not so sure that we need to worry about namespaces. From what I
> hear enthusiasm about them in the W3C is waning, nor does there seem
> to be all that much enthusiasm among implementors.

* Jack Jansen
>
> Oh? I know that _I_ am pretty enthusiastic about them, and envision using
> them for various things...

What kinds of things? And why are you enthusiastic about them?

I envision a lot of pain in implementing them (if we are to do it properly)
so I'd like to know why I have to suffer if I have to. :)

* Lars Marius Garshol
>
> The trouble is that it will be very hard (if at all possible) to do
> this without doing damage to backwards compatibility. 

* Jack Jansen
>
> This, I think, may not be so difficult if we specify a couple of things in 
> advance. For instance (and this is just an example) I can envision that we 
> specify that in DOM you should always check nodes for being of a type you 
> understand before processing them. Then we could add namespaces to a later 
> release of DOM by adding an API to tell which namespaces your app
understands 
> and hiding elements and attributes of other namespaces as different
> nodetypes.

This sounds like a viable alternative, even if it is just a limited form of
support. However, you can do exactly the same (and much more) with
architectural forms, which we already have support for via Geir Oves xmlarch
module. Why do you want to use namespaces instead?

Also, perhaps we should add to the DOM implementations some standard way of
inserting a SAX ParserFilter (something we should perhaps also work on)
between
the parser and the DOM.

This would enable us to do automate things like removing whitespace, joining
blocks of PCDATA that were separated by buffer boundaries in the parser, doing
architectural processing, (for those who want it) doing namespace filtering,
filtering out XLinks for special processing etc etc

--Lars M.