On Tue, May 18, 2010 at 5:59 PM, Heiko Jansen <heiko_jan...@web.de> wrote: > Dear Moose-icians, > > I'm currently pondering on the idea of writing a Perl module for bibliographic > records using the MODS format (http://loc.gov/mods). > Basically there are two approaches I'm considering right now: > a) Using XML::Compile::Schema for parsing and writing the XML records and > utilizing the "typemap" feature to map the structural elements to Perl classes > (probably without using Moose there). > b) Using PRANG to parse/write the XML records and map their elements directly > to Moose-based Perl classes. > > There are a few minor questions related to b) - regarding, e.g., the handling > of attributes belonging to different namespaces - which can probably be sorted > out - read: expect more mails to come ;-)
I don't know about PRANG but XML::Toolkit has XMLNS support in the most recent versions. Out of curiosity why are you looking at PRANG? I ask this as the maint for XML::Toolkit wondering which features to steal / recommend PRANG over XML::Toolkit ... or how to make the interactions between the two easier. > One questions, however, currently looks like a major road block to me - but > that might be just me being ignorant of the appropriate features of Moose: > > The MODS specification has seen a number of revisions already where elements > and attributes have been added, removed, declared (no longer) mandatory, or > where the list of allowed values has been changed. My goal would be to support > a number of older versions and all future versions with minimum effort. > > Writing the perl classes "by hand" I'd require a version attribute and write > custom code in every class / accessor to check for (version-specific) correct > data. > > But how am I supposed to tackle this problem using Moose/PRANG? Changing the > 'isa' property of Moose attributes at runtime based on the value of another > attribute (holding the MODS version number) seems weird. > I'd be glad if someone could describe possible solutions and/or point to > existing code solving this kind of problem. Previous ways I've used to solve this is to make all options possible but not required. That is make a single set of classes handle all possible forms of the input document, and confirm that they round-trip the output properly. However what you lose is the latent validation that simply building a parse tree provides, and that can be "icky". Karen's suggestion elsewhere in this thread about using a Parametarized role is an interesting one, and I suspect something like that where you have different "versions" of the classes and write a custom parser that inspects the version element before continuing on the parse for the different versions of MODS is probably a less "radical" version of this same idea. In XML::Toolkit you'd do this by subclassing the Loader and overriding the parse functionality, it's non-trivial but not exactly rocket science ... it's also never been done so there may be unknown dragons. With PRANG, I hope Sam Vilain speaks up. -Chris
