[XML-SIG] femto-dom?

[Rich Salz]

>   Is the problem that the API is too heavy (it is!), or the DOM
> objects?

I'd say the former, which influenced the latter, althugh I don't care,
since I'm already using the DOM elsewhere in our app.  I just want to
build up bits of an XML document and then output it, using something a
little more elegant than string-pasting.

>  I think an API that wraps a DOM implementation would be very
> nice to have, all would allow the resultant DOM to still be used with
> tools that expect the full DOM.  I expect the wrapper could be
> completely independent of the actual DOM implementation.

That makes sense.  I'd have to learn more of the DOM API, which I don't
have time to do, but I'd gladly "loan" :) the API, tweak it a bit (e.g.,
add a SimpleDocument object), and document it if there are folks who
would work on the other parts.

>   I like the idea of an easier-to-use API.  I can also imagine having
> an API this easy to use that supports both SAX and DOM back-ends.

The easier API has definitely come up here before, so I'm not doing
anything particularly new here.  If by "this easy to use" you are
referring to what I posted, well gee, thanks.

> The SAX backend would be really nice when generating a lot of output
> that doesn't need to be stored in memory.

This sounds interesting, but I don't think I really understand what you
mean.  I keep thinking of co-routines -- push nodes onto the front, get
SAX events out the back -- but since "yield" is fairly new, I don't
think that's what you're getting at.  How else to avoid keeping the
whole thing incore?
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com