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

[Shane Hathaway]

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
> 2.
> 
> I do think namespace declaration in the template is a good idea, if 
> nothing else clearly indicating what namespaces are used and 
> where they are coming from, rather than just being magically accessible.

Here's something else I'm trying to articulate: the syntax is more 
valuable if we leverage existing conventions.  The mapping of prefixes 
to namespaces leads to instant understanding by anyone who uses XML 
namespaces, and increasingly, you can't get far in XML without learning 
namespaces.  In XML, prefixes go with namespaces.  If you take away 
namespaces, prefixes have no obvious meaning, and we have to explain a 
totally new concept to everyone.  With namespaces, it's not a completely 
new concept--it's a new, exciting twist on existing concepts.

The parallels to XML namespaces lead to obvious conclusions: the 
namespaces are decentralized, you can add proprietary namespaces if you 
wish, you can use less-rigid namespaces, you can interoperate cleanly 
with software that depends on specific namespaces, you don't have to 
stake a claim on prefixes, etc.  In short, it gives developers a lot of 
freedom.

If prefixes map directly to components or interfaces, the new syntax is 
really specific to Zope.  Every time you want to create a new API, you 
have to be sure no one else has staked a claim to the prefix you want. 
Even if you're using page templates outside Zope, you have to be sure no 
one in the Zope community has taken your prefix, because you might want 
to interoperate with Zope someday, and you don't want to change your 
prefix.  So effectively, all the namespaces are centralized and 
controlled by Zope.  That could be a problem for interesting prefixes 
with ambiguous meanings like "workflow", "versions", "api", "db", etc.

The crucial difference between Jim's point of view and mine is the 
number of namespaces (APIs) that should exist.  Jim wants one.  I want 
many--countless, even.  If there is only one namespace, or very few, 
URI-bound namespaces are an irrelevant distraction.  If there are many 
namespaces, we need URIs for at least two reasons: to blend with 
existing conventions, and for decentralization.

Shane