[Clipart] XML hierarchy definitions

[Bryce Harrington]

On Mon, 27 Sep 2004, Jonadab the Unsightly One wrote:
> Bryce Harrington <bryce at bryceharrington.com> writes:
> > Basically, we need to pass in an XML file or filename for it to
> > load, 
> 
> For that part, there are a number of XML-parsing modules on the CPAN.
> We should pick one we can work with.  You've been using XML::Twig in
> e.g. SVG::Metadata -- is it suitable for this, or should we look
> elsewhere.  I'm afraid my experience with XML modules is up to now
> rather lacking, unless you count HTML::Tree (which is awesome; if we
> had an equivalent module with basically that same functionality and
> interface but generalized for XML that would be ideal).

XML::Twig is certainly a possible candidate.  I had started with
XML::Simple initially as you may recall, but had to switch to XML::Twig.

> >     $dir = 'my_daughters_aquarium';
> >     %criteria = ( 'keywords:required' => ['fish','freshwater'],
> >                   'keywords:omit'     => ['shark','cooked','nazi','profanity']
> >                 );
> >
> >     foreach my $doc_id ($dms->query(%criteria)) {
> >         $dms->checkout($dir, $doc_id);
> >     }
> 
> Interesting.  What does checkout do?

It basically just creates a local copy of the file in your directory
system.  It's analogous to `cvs checkout`.

> > Still TBD is how to specify that you want just svg's, or svg's plus
> > thumbnails, or everything, or... 
> 
> Those could be options passed to query, either as part of the hash of
> criteria or as a separate hash of options.  Once you have such a hash
> of options, then you can add more options to it later.  Any options
> not specified get the default behavior.

*Nod*

> > Also, I'm iffy on the syntax for the %criteria, so that may change.
> 
> Having it be a hash with lists[1] for the values is a good setup, very
> flexible.  Again, any keys not specified would get default values,
> presumably (e.g., if you don't specify a value for 'keywords:omit' the
> default would probably be an empty list).
>   
> [1] Yeah, I know they're arrayrefs, but we're _using_ them in this
>     case as lists -- i.e., we're not interested in the ability to do
>     arithmetic on the integer index and whatnot; we're just interested
>     in the reading off the values.

Yeah, I know this is a flexible approach, but am concerned that the
syntax may be too complex.  But I'm not going to worry about it much for
now.  If it does the job, it does the job.

Bryce