This is an example of the Strategy Pattern. The library supplies a generic parser that calls back into the user-supplied parsing strategy, which allows the parser to avoid keeping unneeded state. The additional guarantees regarding the sequence of method invocations are just a part of the interface that cannot be expressed within the type system as a method signature.

The intention of the state pattern is different: To allow an object to change its behaviour when its state changes, without excessive conditionals. To that end, each state is represented by a separate subclass. A wrapper contains the current state object and may change the state. Here, the parser API does not have the ability to change the callbacks. However, the supplies strategy may use the state pattern internally.

The intention of the visitor pattern is different: To add new operations to a class hierarchy without changing those classes. The defining feature is a double-dispatch approach that amounts to a safe downcast. Here, there seems to be no class hierarchy that would require a visitor. However, the parser or the strategy may use a visitor internally to deal with different elements (e.g. to react differently to text-, element-, and comment-nodes).

This is an example of the Strategy Pattern. The library supplies a generic parser that calls back into the user-supplied parsing strategy, which allows the parser to avoid keeping unneeded state. The additional guarantees regarding the sequence of method invocations are just a part of the interface that cannot be expressed within the type system as a method signature.

The intention of the state pattern is different: To allow an object to change its behaviour when its state changes, without excessive conditionals. To that end, each state is represented by a separate subclass. A wrapper contains the current state object and may change the state. Here, the parser API does not have the ability to change the callbacks. However, the supplies strategy may use the state pattern internally.

The intention of the visitor pattern is different: To add new operations to a class hierarchy without changing those classes. The defining feature is a double-dispatch approach that amounts to a safe downcast. Here, there seems to be no class hierarchy that would require a visitor. However, the parser or the strategy may use a visitor internally to deal with different elements (e.g. to react differently to text-, element-, and comment-nodes).

This is somewhat related to the observer pattern, as the parsing strategy is notified whenever the parser state changes. As there seems to be no support for registering multiple observers, so I think the characterization as an example of the strategy pattern is more accurate. However, this callback-based parsing you are seeing is absolutely a kind of event-driven parsing.