Re: UrShape XML parser (Was: Shapes layout proposal)

[John Palmieri <johnp martianrock com>]

> That's what I thought of. But the interface will have some extensions
> of which some might not be in a DOM (i.e. integer handling). The
> tree-handling interface would be as close as possible to libxml-DOM.
>

Great!

>
> > Since we are building our own tree then yes SAX is the way to go.
> One issue I have here is saving: I see 2 implementation methods:
> 1. Run through our own tree and create a DOM tree, then use
> libxml:xmlSaveFile
> 2. Do the XML encoding by hand.
> The 1st has the advantage of code reuse, but slurps more memory, the
> second should be somewhat faster and leaner, but takes more coding.
>

Since this would be a one time hit (XML trees are no bigger than your standard
web page) and after the save the memory would be freed, #1 sounds like the best
option.

> I didn't mean to make things too ambitious. I just thought of it as an
> advantage, since once we get to the "scripting" phase, the callbacks
> are quite easy to implement.

Good thinking ahead.  I just don't want to have to redo callbacks when we get to
the scripting phase and find out that because of lack of constancy it won't work
with the scripts.

>
> > I think this is what we have been discussing all along.  Good, you can work
> > on the parser while James works on the internal structure and interface.
> Job taken. I'll mail you when I got through this SAX stuff.

Awesome.
--J5