>> Having the schema versioned with 2.1, 2.2, etc sounds good to me. +1 for versioning the schema - from the tools p.o.v. it makes life easier as things like XML editors can cope better with on-the-fly validation and element/attribute completion options.
> Hmmm so in all other situations with OSGi you need to control > versioning in MANIFEST.MF files > and then suddenly you need to do this specially for Camel? >What > happens when your bundle (which contains the camel xml route) > has X version of Camel in MANIFEST.MF and then schema version have > version Y? You need to keep them in sync? I would attempt to avoid this situation by ensuring that the schema is present in the Camel OSGi bundle, basically tying it to the declared bundle version, then the Camel build can keep them in sync. > If this is the only solution then the people working on 3rd party > tooling such as Fuse Integration Designer needs to be aware of this so > they can add tooling support > for specifying Camel versions in the XML files. With Eclipse at least, versioning in the namespace is the best way to go, because then there's no clash when we register the schema with the XML catalog extension (for editing), plus all we need to do is pull that namespace and key off the version at the end to choose EIP diagram validation strategies and deployment capabilities... cheers --oh