[Zope-CMF] Dublin Core Subject Qualifier Implementation

Jeffrey P Shell jeffrey@cuemedia.com
Wed, 20 Feb 2002 11:00:59 -0700


I raised this issue back when I was still working at Zope corp. We had some
good discussions on it, but I don't think it amounted to any more than that.
I do think that the __init__ issue is significant, especially since it calls
the DefaultDublinCoreImpl class by name, making it difficult to substitute
in a new DublinCore handling class without having to rewrite (or guerilla
patch) lots of __init__ methods if you intend on using the other content
classes in CMFDefault.  I started writing up a proposal in an outliner, and
one of its proposed solutions was to extend the metadata tool to be able to
include Parser objects, which could be object instances, Python scripts,
External Methods, etc.  For example:

def SCSV(md_string):
    """ semicolon separated values """
    return tuple(md_string.split('; '))

def as_SCSV(md_data):
    """ join sequence of data as semicolon separated values """
    return '; '.join(md_data)

This could be conjoined with metadata about the metadata :).  Basically, the
metadata tool could include the following information:

 o Name
 o Default Scheme (parser, ie 'SCSV')
 o Setter / Getter
 o (optional) Encoder
 o (optional) Validator

All or most of this information could be configurable through the metadata
tool.

There's probably nothing stopping anyone from implementing an improved
metadata tool by themselves, except for the fact that you'd have to also
write a new DublinCore mix-in class that would be aware of your extensions.
And, as noted, the problem there is that all of the default content types
rely heavily on the DefaultDublinCoreImpl.

A risky but potentially fun solution could also involve some dynamic context
wrapping of a content object in an improved MetadataHandler, assigned by
type configuration, that would catch all the calls to metadata getters and
setters and run them through various encoding and validation schemes.

On 2/20/02 4:06 AM, "Tim Hoffman" <timhoffman@cams.wa.gov.au> wrote:

> Hi
> 
> I would like to add my 2c worth on the general topic of Metadata etc.. whilst
> the topic is currently raised.
> 
> We have been extending the defaultDublinCore implementation with Hotfix's to
> add additional elements such as those found in the AGLS, but I have to say it
> seems to be about the only way to transparently add it to all content objects.
> 
> I find this starts to show deficiencies in the metadata model as implemented
> in current CMF because we see inside objects such as all the init methods for
> content types in CMFDefault actually specifying all of the core dublic core
> elements as arguments (whoops).
> 
> Which means that if you really wanted to take advantage of their use in init
> methods I would then have to override a whole bunch of init methods which
> would not be fun. Thankfully we can go through metadata edit etc...
> 
> But what it does show is that we need to have a different model of defining
> and registering metadata schemas to be included with content objects.
> 
> At a simplistic level using property sheets might work, but as this discussion
> on IPTC subject qualifiers, and my own experience shows,  I need (at least) to
> be able to have custom getter and setter methods for each of the elements to
> enforce validity of contents etc,...
> 
> My wish would be to have a metatdata registry (a bit like the types registry)
> where one could add metadata elements, plus bind getter and setter methods to
> each element.
> 
> ohh I should have checked in the Zope3 discussions to see if this sort of
> thing or a similiar dynamic binding model has been discussed. It's late, and I
> should be home.
> 
> Any thoughts on this?
> 
> Because I may have to look at doing this pretty soon.
> 

-- 
Jeffrey P Shell 
www.cuemedia.com