Hi Markus,
The issue is that the configuration interface was developed in a way that it expects each conceptual schema to have its own individual address. Changing the interface can be a bit tricky, but I'm sure we can find some workaround. One way would be something similar to what you suggested: a CNS address with multiple schemas would make the configurator download them and display each one in the existing list of pre-defined schemas that can be selected by the user. Another way could be to include a fake parameter in the CNS address to specify the conceptual schema (this one doesn't look so nice but it somehow simulates a real service).
Regards, -- Renato
On 19 Mar 2007 at 16:29, Markus Döring wrote:
Hi guys, nice to see you are progressing!
An important idea behind having multiple schemas inside a CNS is that it acts as a single entrypoint. Remember that we intended to replace the CNS alias.txt file with a real webservice. Having only 1 entrypoint gives you one really big advantage. As soon as you update this file, all providers are aware of this! In the case you want to add a new CNS file, every service has to be reconfigured. Thats easy to do, but someone has to do it and it will take a long time til it spreads through our entire network. We could surely have another registry of CNS files, but that sounds to me a bit over the top. Can you explain to me again why having separate alias.txt files is important for TapirLink? Couldnt you just read the entire file and locally split it into cached separate alias.txt files? -- Markus