Re: Keystone Application Framework implementing SVG graphics

>>I would very much encourage you to do that. What specific aspect of the
>>XML syntax currently requires hand editing on your part?

JL> My implementation throws exceptions and dies on loading any
JL> unsupported element at present.

CL> Ah, okay. I was thinking of problems with
CL> doctypes/namespaces/entities/CDATA sections. Unsupported elements are
CL> easier, in fact.
I'm using an XML parser in the framework (Expat), so this mostly takes care of the dirty
details for me.  A lot of structure can be ignored unless you ask for it with Expat.

JL> This means it can't load some of the test suite examples it cannot render, but also as
JL> for example the <desc/> element is not implemented, it can't load any of the test suite
JL> examples at present.  (though <desc/> isn't needed to render them of course)

CL> Same for metadata. OK well, it seems that for all the unimplemented and
CL> non-rendering elements, you can have one, no-op handler. And in fact,
CL> using that handler for any unknown (but well formed) element might be a
CL> good idea.
The framework creates an object of a class matching the element name for each element,
so an unhandled element is caused internally by 'class not found'.  Throws exceptions and dies at
present, but I'll be changing to simply ignore unhandled elements (need to ignore their
children too of course)

JL> Sounds good.  Send me the results file any time, I'll be keen
JL> to see the format.  I'll provide an application
JL> to render the SVG test suite examples when ready

CL> Excellent, I look forward to that. The format is no big secret, here it
CL> is (three xml attachments)

Thanks for that, looks straightfoward.  My submission is coming, and hopefully not too far off.
My implementation runs on multiple platforms, should I just pick one and do the testing on that?  
I see there is a field for 'platform' in the result file

Jacob

Received on Monday, 26 July 2004 09:04:41 UTC