>>>>How would you suggest handling it with Cocoon today? >>> >>>Since you *have* to define up front between groups which URLS to use, >>>and define them with no general rule, simply make a FixedListMatcher >>>that matches based on fixed names in a list, so that you don't need an >>>expert system and just need to update a list. >> >> No you don't have to define up front what groups use what URIs. That's the >> whole point of using sub-sitemaps. All I have to define is what part of a >> pattern each group uses. > > Exactly. By making sitemaps return, you are *not* defining the pattern > each group uses. You are leaving it all to them.
Sigh, I am defining a pattern each group uses. They may not fully use all of each possible name space, that is true with Cocoon today. More-over, I am also defining a back up use of the name space if and when the two groups agree that they are going to have an overlap. The point is, it's not the maintainer of the master sitemap that is writing the "contract" on how the name spaces are being used. It's two other groups (well actually half a dozen, but that's another problem). >> It's up to the groups to define what URIs to use, >> not me. > > Ok, then what's the problem? > Can't they change the sitemap? 1) they can't change the master sitemap. They can only change things in their own directories. 2) Currently they can make all the changes they want to a sub sitemap. However, if someone else's sub sitemap gets control first their sub-sitemap will never even have a shot at having the URI handled. >> I don't want to be in charge of this; I don't want anyone in our >> group to be in charge of this. I want the end users to work the URI >> mappings out between them and I want the sitemap to still work when they >> decide that one groups URIs overlaps the root of another groups URI. > > Ok, then give them a subsitemap they use together. > If they decide URIs together, they can surely work on the same shared > sitemap together. > And have other subsitemaps there. If it was just two groups that might be a reasonable solution. What happens when it's 6 and they don't trust each other (they have a long term political history of not cooperating, thus the tortuous every 2nd Tuesday meetings where they negotiate the web site lay out). You end up with N combinatorial combinations of directories and sub sitemaps if you have to allow for secure and deterministic handling of each possible source of information. I should point out, once more, that our real life situation has nothing to do with the examples given here, though they are in many ways similar. The real version of the problem requires serving up research results from, at present, over 600 different research protocols (we've got about 20 implemented), each of which is essentially administered as though it was an independent kingdom, but with requirements to share information on a very restricted basis. >> The >> fact that I give them default sub-sitemap matchers of "IT*" and "Stats*" >> shouldn't be their problem if they decide that IT has a good reason to match >> "StatsSomethingStrange" for some specific URI. > > Sure, then mount a sitemap and give it to them... both of them. Can't be done, they would not ever agree to share a common directory for all their information which is what this would require. Now I could give them the capability to define a sub sitemap that then delegated to two other sub sitemaps. However, now all I've done is shove the problem down a level and the two groups will have the same requirement that I do. More-over, for the case when the problem has to be scaled to work with N groups you once more have possibly N combinatorial sub-sitemaps deciding which sub-sub sitemap to parcel the information out to. >> Once again, I ask you to tell me how to handle this situation with Cocoon as >> it currently sits? > > I have already said it. More than once. No, you've come up with a solution that shares data instead of sharing metadata and thus doesn't solve the problem. The requirement is to allow each group to securely maintain their own information while sharing some of the same URI name space (not some of the same information). [snip of redundant discussion] >> >> Throwing an error is not graceful behavior as far as an end user is >> concerned when they have every reason to expect their URI mapping to work! > > You don't listen. > If there is URL overlapping there is no way you can handle the situation > gracefully if the groups don't work together. As I've repeatedly pointed out, the two groups do work together. That's not the problem. The problem is how to allow them to share some common URIs (or better Cocoon matching patterns) in a graceful manner without requiring the maintainer of the master sitemap to be involved in coding up their resolution to their problems. >> You handle the mapping, you are in charge. >They handle it, they are in charge. > > Read the SoC part of > http://xml.apache.org/cocoon/introduction.html Now that's ironic. Here's the separation of concerns I need: 1) Master Web site maintainer, in charge of maintaining the application server. 2) Many independent groups, each with their own, securely served and maintained data. 3) Ability for each combination of independent groups to come to agreements between them on how to share URIs (really Cocoon matching patterns since you can match on more than URIs) without involving the master web site maintainer. >> If you stop to think about it you'll realize this is true for almost any >> system other than simple static screen displays: what data is presented is >> based on session values, or request values, or cookie values, or whatever. >> As such, saying that a URI map should _always_ be required to be >> deterministic is nonsense. > > Is it magic? Sorry, I should have stated that as; "saying that the top level of a hierarchy of URI maps should always be required to be fully deterministic, in-and-of-itself, is nonsense". I think you're missing a big chunk of the problem: it's not just URI matching that's the problem here. Cocoon sitemaps can match based on (literally) 1000's of different pieces of information. You can considerably simplify the coding of Cocoon sitemaps if you can move some of the responsibility for handling the matching down to sub sitemaps without having such a decision being isolated to a single sub sitemap. >> There may be very good reasons for a sub-sitemap >> to look at other values associated with a URI and reject the handling of >> that particular URI. There may be very good reasons why some other >> sub-sitemap could then subsequently handle that particular case. If I have >> to code all the matching rules in the parent sitemap I've defeated the >> purpose of the sub-sitemaps. > > Hmmm... manybe you've defeated *your* idea of subsitemaps. > > Linux can mount. Cocoon can. Same concept. No, it's not the same concept (see the following)... > Would you like the mount point to have a multiplicity? > What file does the user get? First off, we're not serving files, the analogy is flawed in it's conception since if all you needed was file serving you wouldn't need Cocoon (Apache would suffice). However, the decision on what information to be displayed would still be based on whatever match is made first, the same as today. I've just separated maintenance of the rules among multiple groups instead of requiring them to all be maintained in one spot. Instead of thinking in terms of file matching think in terms of XSLT template pattern matching; it's not restricted to just a single dimension of matching (unlike file systems). Think of how restrictive XSLT would be if call-template was not allowed to return to the calling template! > Read the *original* proposal of the sitemap in the archives, and you'll > understand why a sitemap is not reactive: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=86952206811879&w=2 That doesn't change my argument, if anything, it enforces it: allowing a sitemap to return allows me to build overlapping hierarchies of patterns without having to code for all such possibilities in one spot. As such, it allows for better SOC, not worse. >> I've >> given you many reasons why it could help people. > > It helps people do what I think is bad practice. > > A citation form Mazzocchi, which I think still stands: > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=86952206811915&w=2 > Again, if anything this reinforces my argument. I'll try to show how by interjecting my comments into the quote (though it seems sort of messy to do so). > " > 1) badly designed web sites will lead to verbose sitemaps, on the > contrary, well designed web sites will need less verbose sitemaps. Allowing returns from sub-sitemaps would allow one to code less verbose sitemaps since you would no longer require that all possible URI patterns are explicitly named in the top level sitemap. [point 2 about being nice snipped] > 3) a good sitemap grows step-wise logarithmically with the web site > size. This means that once you've reached the needed web-site > complexity, every addiction in the same patterns will not need to modify > the sitemap, or, if it does, produces redesign rather than simple > verbosity increasing. Allowing sub-sitemaps would, in some cases, allow top level patterns to be coded once and forever, without a need to ever redesign the top level sitemap. Changes would be isolated to incremental changes in sub-sitemaps. It could considerably reduce the size of a sitemap since generic matching rules can now be used in catch all sub-sitemaps when specific rules in prior called sub sitemaps do not match. > 4) Cocoon is _not_ designed for small sites. Small sites will have > complex sitemaps compared to other solutions. This is why I do not > recommend Cocoon for pure HTML replacement. Allowing sub-sitemaps to return helps in the management of large web sites by allowing negotiations on sitemap matching to occur on a one to one basis instead of an N combinatorial basis. The maintenance of such sites can then be parceled out to multiple groups knowing that they are free to manage the site as they see fit without the involvement of some third party. > 5) I assume sitemaps will be managed by learned people that keep control > of the "contracts" between the working contexts. This is the > "management" box in the "pyramid model of operation" (see Cocoon docs). Allowing sub-sitemaps to return can allow the people who are negotiating the pattern matching contracts to manage their contracts directly instead of requiring that some master sitemap maintainer code the contract for them. >> Even if you don't agree >> with my reasons -- if you want people to respect your votes -- I believe you >> need to give us some real justification for not allowing this change other >> than the fact you think "it is not right". > > No listen to this! :-O > > I have not voted, Huh ? http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103416369316569&w=2 shows you voting -1 on this issue ???? If that's not correct, or you'd like to revoke your vote, then forget the whole issue... > I have explained it as much as I can, I spent my time > explaining you how it can be done better, and this is the result? Sorry, but you really haven't explained how to meet my concerns at all. You've tried to map my problem to your way of using sitemaps, but that doesn't address the real problem. [snip on suggestion that research groups have copious spare time to maintain independent branches of Cocoon source code] >> However, I'd like you to once more go back >> and look at this. I for one strongly believe that the ability to >> _optionally_ parcel out handling of a URI to multiple sub-sitemaps would >> help for some organizations and that adding such capabilities to Cocoon >> cannot hurt anyone. > > This "cannot hurt anyone" is the usual refrain. :-/ If you could really give me one real life example of how allowing this change would hurt things I'd listen to it. [snip on introduction to following] > Now, it seems to me that in your organization, you are the Cocoon admin, > and are in charge of the main Cocoon sitemap. > There you can give groups subsitemaps that are mounted, thus > partitioning the space between them. > > Some groups work separately while still sharing the same URI space > somewhat, and try to work out the inconsistencies with weekly or > as-needed summits ;-) > > You want to be able to have them work *indipendently* on the *same* > mount point. No, I want them to work independently on different mount points. I want them to share the responsibility for maintaining a URI name space (or more correctly, maintaining Cocoon matching patterns). The problem is almost the exact opposite of what you discuss. [rest of discussion snipped since it discusses how to share information and not how to share matching capabilities] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
