[PEPr] Comment on Semantic Web::XML_GRDDL

Till Klampaeckel (http://pear.php.net/user/till) has commented on the proposal for Semantic Web::XML_GRDDL. Comment: Hey Daniel, looks pretty interesting. Just giving you feedback to a few of your questions. And a couple Qs in the end. On Sat, Mar 1, 2008 at 4:20 AM, Daniel O'Connor <daniel.oconnor@gmail.com> wrote: > 2) I have a pre-rendered out RDF/XML document to compare my generated > (...) > - there's no PHPUnit::assertEqual($xml, $other_xml); which handles all > of the ins and outs that a string comparison won't cut it for. Can you explain this? Are you talking about the difference in linebreaks and possible whitespace? Or what exactly keeps you from a simple string comparison? > 3) Caching - what are good implementation strategies around this? > IE, Caching vs development, in one scenario you need it for > scale/performance, in another you need it to get out of the way. > > What existing packages are there that use Caching, and would be > considered 'best practice'? I'd personally allow this to be a configuration option. E.g. add an optional dependency on Cache_Lite and create an object on demand. Also allow users to configure the Cache_Lite (e.g. lifetime, backend/path) and/or add support to allow users to inject their "own" instance of Cache_Lite into the class. For example, someone is using Cache_Lite already so why re-create a second instance when your code can re-use his? How the users configure your class (with or without caching, or supply their own instance of Cache_Lite) is up to them. (user = developer) > 4) Logging & Exception handling > At the moment, I'm just throwing plain Exceptions and avoiding causing > them. What's the most useful way to provide robust exceptions; but > swallow the unimportant ones. I think the idea is to make your class's exception (XML_GRDDL_Exception) to extend PEAR_Exception. I haven't looked at your code yet, but generally if you are subclasses throw an error, I'd also throw a distinct exception. And last but not least also define class constants to define error codes. For example if you experience a request error: PEAR_Exception |- XML_GRDDL_Exception |-XML_GRDDL_Request_Exception I always get a bit carried away with different exception classes, but I like them for a reason: try { // your code } catch (XML_GRDDL_Request_Exception $e) { if ($e->getCode() == XML_GRDDL::ERR_NOT_FOUND) { // -> we found a 404 } else { throw $e; } } catch (XML_GRDDL_Exception $e) { // -> handle general errors } catch (Exception $e) { // -> handle all other errors } A logger is also nice - e.g. for debugging. I think it all depends on how complex your class is. I don't remember right now which PEAR package implements one, but (I think) I've seen it before. Just my 2 cents. :-) Generally I have a few Qs about this thing - from what I read the objective is to convert Microformats into RDF? What do I do with it then? (Just curious. :-)) RDF looks pretty complex also. I also found this pretty comprehensive example on your wiki: <http://code.google.com/p/xmlgrddl/wiki/UsageExample> I see hcal, hcard, etc. - can you list all (currently) supported microformats? Did you implement a driver-based architecture to meet the different demands of how people want to query for microformats? (Sorry, but) I couldn't really figure this out. Last but not least - (pure curiousity) is GRDDL always about RDF, or can we "expect" other response formats also. Or what do you suggest to use? Last but not least, the links to your examples are broken. I think Google recently changed their SVN browser. Till Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=533 -- Sent by PEPr, the automatic proposal system at http://pear.php.net