[Clipart] XML hierarchy definitions

[Jonadab the Unsightly One]

Bryce Harrington <bryce at bryceharrington.com> writes:

> "Unwarnock"?

Warnocking is the opposite of bikeshedding.  Bikeshedding is when
something is simple enough and unimportant enough that as soon as
someone mentions it everyone and his brother trots out an opinion and
you get a long thread:  "what color should we paint the bike shed".
Warnocking is when something is important, but someone brings it up
and everyone just waits for someone else to say something, and so it
promptly falls off the radar.

Unwarnocking is when you bring a warnocked topic back up and talk
about it.

> What we're going to need is a routine that takes this xml hierarchy
> and pulls the corresponding items from the dms into a matching
> directory structure.  

Directory structure?  I thought we wanted the various tools (browse
and so on) to read from the DMS directly?

Or maybe you meant just a data structure that's like a directory tree,
in that it's heirarchical?

> This should also include options for specifying what to pull - for
> instance, whether to pull just the svg's, or to pull thumbnails too,
> and if so, which size to grab.

Right.  So as arguments you're going to feed it an XML heirarchy (as a
string most likely) and some options (in a hash probably).  And it's
going to return...  a nested data structure whose leaf nodes are
handles or magic tokens that can be used to retrieve files from the
DMS, is that about right?

So the calling code would do something like this...

my $stuff = whateverwecalltheroutine( $XML_heirarchy_en,
   { fetch_SVG => 1,
     fetch_PNG => 0,
     include_thumbnails => [ 64, 128 ],
     include_metadata   => [ 'title' ] });

And then $stuff might look something like this...

[
  { categoryname  => 'Animals',
    subcategories => [
                      { categoryname => 'Mammals',
                        images       => [
                                          { title => 'Gorilla',
                                            token => 'id12984',
                                            thumbnails => [ 64 => 'id12986',
                                                            128 => 'id12987' ] },
                                          # ... other mammals go here
                                        ],
                        # If Mammals had any subcategories they'd go here.
                      },
                      # Other Animals subcategories go here.
                     ],
    images        => [ # Images loose in the Animals category go here.
                     ],
  }
]
 
Obviously that's just a rough sketch of the general idea.  Anyway, if
the calling code then wanted to get the 128-pixel thumbnail for the
Gorilla image, it would ask the DMS for object 'id12987'.  (The tokens
might not look quite like that, but they'd be some kind of unique id.)
Presumably, it could ask the DMS for a URI pointing to that thumbnail,
or it could ask for the actual content...

my $gorillathumbpng = get_from_DMS(id => 'id12987'); # binary PNG content
my $gorillathumburi = get_from_DMS(id => 'id12987', format => 'URI');
my $gorillasvg      = get_from_DMS(id => 'id12984');

Am I making sense?
                                                           
> Also, I think we will want an 'update' watcher function that can add
> new items to an existing directory structure.  When the dms receives
> new images, it will notify all registered watchers that it got new
> stuff; the watchers will determine if they want the material (i.e.,
> if it's in the appropriate 'state', has a keyword belonging to the
> hierarchy, etc.)  and if so, pulls it and places it in the
> appropriate location in the directory structure.

I was thinking that the directory structure would be returned on the
fly by the DMS based on the XML and the database of content it's
storing.  However, watchers still might be useful for various
things...

 * Notifying the maintainers of certain keyword categories by mail
   when images are added to or removed from their category.

 * Automatically generating any missing thumbnails, so that all
   images in the DMS have thumbnails at all the desired sizes.

 * We might want to have an index listing each keyword, and all
   the objects in the DMS that have that keyword, to facilitate
   faster searching.  Those would have to be updated whenever
   an object is added or its keyword list modified.

> Possibly a perl module already exists that does some of this...
> Anyway, maybe it's too advanced for us right now, but if you think
> you could hack something into existance, I could help out with the
> bits to pull items from the dms.

I haven't really looked at the DMS in any depth yet.  Back when I
wrote up that sample XML, I was still thinking about a browse script
looking through all the SVG images stored in a single directory to see
which ones have certain keywords, and presenting them in the
categories that have those keywords in the XML.  That obviously won't
scale well, though.  The DMS is the better way to go.  It seems like
your work on that is turning out to be the real heavy lifting of the
project.  Some more of us should probably look at your DMS code and
see if we can help out with that too, because long-term I suspect the
DMS may be the bulk of the programming work.  The web interface (which
is most of what I've been working on, and a couple of others too) is
the easy part, ultimately.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/