>A streaming API which defines a handler with a method that gets the name >(or path?) and the map of properties would avoid having this additional >tree api. I don't see a huge need to be able to have an api to traverse >the parsed content. If any user of the contentparser really needs it, it >can use whatever it wants.
a Stream API would be a good solution for one half of the use cases. the other half benefits from a Traversing API - we may leave it to the other bundles and live with some code duplication. before dropping traversing API completely - what about this: we rename the traversing API to something that makes it obvious that this is not yet-another-content-representation-api but only a tool to hand over data - e.g. "ParsingResult" instead of "Content"? the solution could be: - offer a Streaming API - offer an optional handler based on this streaming API that produces a "ParsingResult" that has the minimal traversing capabilities as outlined in the PR. we could even put this in two separate modules, but this feels a bit over-engineered. stefan
