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
On 14.03.2007, at 13:16, Renato De Giovanni wrote:
Hi Roger,
Does this break anything in the ideas behind a TAPIR network? It is not likely to lead to a bad multiplication of CNS files as there are only likely to be around 10 maximum for the ontology. What do you think?
I see no problems in having separate CNS files for each conceptual schema. It doesn't break anything - actually TAPIR capabilities responses can even advertise more than one CNS.
In principle the new CNS handler for TapirLink could just fetch the first conceptual schema from the file. Otherwise we would need to either change the interface or create parameters to the handler.
Maybe the main CNS file that we have now for DarwinCore and ABCD versions could also be separated into different files... (Markus?) Perhaps there could be other advantages in doing that.
Best Regards,
Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir