On 10/17/06, James M Snell <[EMAIL PROTECTED]> wrote:
At this point, so long as we maintain the incremental parse model, preserve the lightweight memory footprint, and can still support xml sigs and encryption, then I'm fine with moving away from Axiom. Like I said, I could likely have something implemented in about two weeks.
I think there are a number of things Axiom is keeping us from accomplishing, and that moving towards something else would probably be a good idea. Personally, I'm interested in the following goals: 1) The ability to have extensions that don't peek into the parser implementation. 2) The ability to do async parsing (i.e. a getFirstSibling() on a node would have the option of returning "nope, ain't got that data yet". Note that option 1 can naturally be made to go away by dropping the concept of having multiple parser back ends. I don't know if that's something we want to do, but it might be. I know that James has mentioned the existence of alternate back ends within IBM, my real question is what is the motivation for the existence of such things. Are there problems they are trying to solve by using an alternate parser that we could solve in our default? Alternatively, we'd need our model to expose more information, so that we can do things like "insert new node into the tree here" without having to dip into the guts of the parser. This would allow extension nodes to live as full citizens alongside nodes that we create via the parser. Of those two goals, I'd say 1 is far more important than 2, but I do think that 2 is worth thinking about. If it's difficult or impossible to do this sort of thing with Axiom (and I think they are impossible, from the investigations I made last week), I'd be definately in favor of dropping it and moving on with something else. -garrett
