[Zope3-dev] Re: Better access to APIs in paths (was Re:needingviewsclues - template/title troubles)

[Tim Hoffman]

Hi Shane

This is fantastic, (and is what I believe you where saying)

I raised this back in June last year on zope3 list, 
because I need something  metadata namespaces and in Zope2,
I needed to extend dublincore and generally get to more metadata 
fields in content. I felt what I had to do in zope2 was way to messy
just to extend DC with AGLS, because DC is so hardwired into
all the content objects/base classes etc. 

http://mail.zope.org/pipermail/zope3-dev/2002-June/002252.html

What I was looking for then (I too could not express it well enough),
I believe is right down the path that you have described.

I can't vote strongly enough for this direction.

This would also allow me to create composiet views of metadata from
different schemas.

Whooohoooo!!

Rgds

Tim Hoffman 

On Wed, 2003-02-26 at 12:36, Shane Hathaway wrote:
> On 02/25/2003 08:48 PM, Tim Hoffman wrote:
> > I just love where you are going with this. I have wanted/needed
> > a clear concise way of representing multiple names spaces
> > specifically for metadata (DC, AGLS etc ..) for quite some time in Zope
> 
> Yes!  I haven't found a way to articulate this until now.
> 
> Even more than accessing APIs, I want to access metadata namespaces 
> through this syntax.  Tim wants to display some AGLS info about objects. 
>   It should be possible to use the syntax proposed to display this 
> information.  No "API" concept is involved here.  Tim isn't using an 
> "API", he's just reading metadata.
> 
> This is the first time I've heard of AGLS.  Apparently it's an 
> Australian metadata standard designed to make government services more 
> accessible to the public.  It's one of *thousands* of metadata standards 
> that are being published now.  There's no reason people should be 
> required to configure anything or write Python code to store and display 
> information from many of these emerging metadata schemas.  They are too 
> simple for that.
> 
> So what I'm proposing is not limited to programming APIs.  To me, it was 
> a happy accident that the syntax I proposed seemed useful for accessing 
> Zope APIs.  What's more important to me is making Zope play well in the 
> world of metadata.
> 
> Metadata is a buzzword, I know, but I think it's a part of the evolution 
> of software.  Users have always been constrained to entering data based 
> on a fixed schema that slowly falls out of touch with actual 
> requirements.  The metadata "movement" is an attempt to break out of 
> rigid schemas in all kinds of software.
> 
> This is what I had in mind when proposing the syntax.  So I was 
> surprised when Jim wanted to take explicit namespaces out.  Without 
> explicit namespaces in templates, you can't use this syntax to access 
> custom metadata without configuring something external to the template. 
>   The template can't specify what metadata it relies on--it has to hope 
> that the particular metadata schema you want is available through the 
> environment.
> 
> For APIs, we can mandate that people don't remove methods from their 
> APIs or change method signatures.  We can successfully maintain that 
> requirement because of the limited scope of Zope.  But we have 
> absolutely no control over metadata schemas, since nearly all of them 
> have no current association with Zope.  That's why explicit namespaces 
> are so important.
> 
> So if we don't allow explicit namespaces, the proposed syntax will be 
> good enough for accessing APIs, but not quite right for accessing 
> arbitrary metadata.  I can live with that, but that's just not what I 
> intended.
> 
> Shane
>