Elements

We already mentioned sax:start-element and sax:end-element. Here's how they work:

CL-USER> (cxml:parse "<outer xmlns='http://namespace'><inner/></outer>" nil)

0: (SAX:START-ELEMENT NIL "http://namespace" "outer" "outer"
                            (#S(SAX::STANDARD-ATTRIBUTE)))
 0: returned NIL

 0: (SAX:START-ELEMENT NIL "http://namespace" "inner" "inner" NIL)
 0: returned NIL
 0: (SAX:END-ELEMENT NIL "http://namespace" "inner" "inner")
 0: returned NIL

 0: (SAX:END-ELEMENT NIL "http://namespace" "outer" "outer")
 0: returned NIL
NIL

Observations:

You get one event after the other in a streaming fashion: There is no nesting of methods for nested XML elements! In this respect, what you get is almost like a serialized XML document.
Aren't those names redundant? Yes, somewhat. You get both the qualified name and the local name, plus the URI. The prefix is part of the qualified name. Naive XML use often depends just on one of the names; reusable code should look at the local name and URI.
All those arguments are convenient to process, but a little less convenient to generate manually because there are so many. The lesson is that SAX calls are useful but a bit technical, and their generation is best hidden under easy-to-use high-level APIs. It's easy to write such high-level APIs though!
The return values seen in the trace output are usually uninteresting and get ignored; from this point on we won't show them anymore (with the exception of end-document's return value, which we'll discuss next!).