Make use of namespace URIs consistent

Reported by Jan-Wijbrand Kolman on 2005-06-20
Affects Status Importance Assigned to Milestone
Kit Blake

Bug Description

There's mulitple locations where we define a namespace URIs within the domain. They need to be checked (and modified where necessary) for

Guido Wesdorp (guido-infrae) wrote :

All nice and all, but not before the 1.3. Deferring until after the 1.3 final.

Andy Altepeter (aaltepet) wrote :

There would actually be a bit of work to here, in terms of processing during upgrades. I'm thinking if metadata sets need to change their namespace URI's. A content's metadata is stored in _portal_annotations by the namespace URI, so all content would need to be updated.

Andy Altepeter (aaltepet) wrote :

Kit, Silva 2.2 is touching all metadata (to upgrade to zope 3 annotations/metadata), so now is probably the best and only time to do this. Metadata set uri's are the big thing that need to be standardized here. We already have a metadata upgrader for 2.2b1...what do you think? Is it important enough to do it, or not?

Changed in silva:
assignee: nobody → Kit Blake (kitblake)
Kit Blake (kitblake) wrote :

Yes, if we're ever going to fix this, now it the time. Am I reading this correctly that, because of the switch to zope 3 annotations, all pieces of content in a site will need to be upgraded? In some of the bigger installations could take days....

Anyway, grepping around I've found the following:

Anybody found any others?

I suppose if we're going to standardize, is the way to go. Is that what you're thinking in terms of changing the metadata?

Andy Altepeter (aaltepet) wrote :

Yes, Products.Silva.upgrade_220 has a MetadataUpgrader, which migrates metadata from obj._portal_annotations to a real Zope3 annotions object, then copies over the metadata from the old to the new. Ouch, expensive for sure in large installations. IN the old metadata way, _portal_annotations is a dictionary with the namespace URI as the key, and the metadata for that set as the value. So, during the upgrader instead of copying directly, change the namespace if needed and then copy. I can't image this would add much additional time to this already expensive upgrade.

Your call.

notal appears to be used only once in the silva core, in views/edit/Container/ I think it was intended for 'disabling' a tal statement. This would be easy to standardize, as it's only in page templates.

Kit Blake (kitblake) wrote :

This has gotten more complicated now that we've examined the exports too. I've found the following:

~~~~~~~~~~ (not in Silva, unless it's in DL objects) (only in use in one template where we can remove it)

Old export
~~~~~~~~~~ (doesn't matter)
xsi:schemaLocation=" silva-0.9.3.xsd" (doesn't matter)

New export header
<silva xmlns=""
xmlns:doc="" xmlns:silva-content="" xmlns:silva-extra="" xmlns:silvanews="" datetime="2009-05-22T10:32:01Z"
silva_version="Silva 2.1.3"

If we change the metadata namespaces we'll have to modify the import to allow imports from previous Silva versions before 2.2. (We don't need to support the 'old import'.)

What will not work is zexp imports from older Silva's I don't think there's any way around this.

After discussing the variants we've decided on Thus, not plural. This has the advantage that *none* of the old namespaces will work any more and we'll be sure to find all places where they're used.

So let's do it.

Sylvain Viollon (thefunny) wrote :

    The old import have been marked as deprecated in 2.1. and removed in 2.2. So yes, no need to support it.

Andy Altepeter (aaltepet) wrote :

Note to self: for the new xml imports, I wonder if it would be possible to do a pre-translate to change the namespaces prior to the actual import? Perhaps either xslt or just regexp...since we have a fairly complete list, and if the import encounters an unknown one, then raise an error?

Andy Altepeter (aaltepet) wrote :

also note that this namespace: is in kupusilvahelpers.js, and likely in the kupucontent in the silva news edit view.

Andy Altepeter (aaltepet) wrote :

I've removed notal, updated all namespaces I could find, got kupu working with the new namespace (SNN properties broke).

There is also , which is the namespace for the zcml extensions. I have not touched this yet.

The next step is to add an upgrader to change the namespace for existing metadata sets (if that doesn't happen already, e.g. through the services refresh), and then adjust the metadata upgrader to change the namespaces for annotations.

Sylvain Viollon (thefunny) wrote :

Changing the ZCML namespace is going to break all compatibility for extension between 2.1 and 2.2 which use them. Something I tried to avoid. Maybe we should support both (if it's doable) with a deprecation warning.

Kit Blake (kitblake) wrote :

If we can support both that would be great. If we can't, bleauugh.

I also notice there's an inconsistency here:
where we use an underscore, while all the others have a dash.

We should make the zcml namespace consistent with this and also use a dash:

Andy Altepeter (aaltepet) wrote :

There is now a metadata upgrader in Silva 2.2. which will upgrade the namespaces stored in content. Namespaces in all known/identified metadata sets have been changed.

Changed in silva:
milestone: none → 2.2
status: Confirmed → Fix Committed
Kit Blake (kitblake) on 2011-01-19
Changed in silva:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers