>> 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... > > My vote was about breaking existing systems. > You said that you would put an attribute "switch" for it, so that > effectively makes my -1 invalid.
Ahh, that wasn't clear. It would have helped enormously if you had said so in response to the notation on having the switch -- that is what I am used to seeing on other (admittedly non-Apache) collaborations. I assume, therefore that we do not need to propose any of this over again? > I don't like to give indipendent coders the possibility of sharing > matching capability in different sitemap files. Can you explain why not? You can already code such matches today. However, there is no chance for anyone else to have a chance of making the match if the first sub-sitemap invoked doesn't make a match. That can leave the owner of the second sub sitemap confused and powerless. > But I continued this thing because I see that you have a point somewhere > in the mails, I appreciate that, this is, for us, an important problem. > but I don't like the solution you propose nor I see how > this fits in Cocoon URI management from a broader perspective than just > you departmental needs. Once more; matchers are more than just URI pattern matching! The example I gave is of necessity simplified. However, let me try and restate it, since it is a generally applicable problem: URIs are by design hierarchical. Many organizations have a matrix management organizational structure where there are multiple owners for many areas of concern. Each organizational domain may have needs to securely manage their own information. Cocoon lets one break out of the hierarchical URI restrictions by allowing one to match on attributes other than just the URI itself. The current sub sitemap implementation does not conform to this general pattern since it forces a strict one-way hierarchy on the way that sub sitemaps can be used to match information requests. Thus, as currently implemented, sub sitemaps break the general applicability of sitemap matchers in the sitemap. > I gave you concrete possibilities you can use *now*, like xml entities, > but you haven't even commented them, No, you have not given us any concrete solutions. As I've stated, the problem is not how to share information or aggregate information (as your proposed solutions would allow). The problem is that the Cocoon encodes meta-data in the form of sitemap rules. This meta-data tells Cocoon what information is to be displayed in any given context. I need to be able to share the coding of this meta-data between multiple independent subgroups in some manageable way. I need to allow the meta-data to work in a variety of situations that cannot be easily handled by having one group manage all the metadata on behalf of all the other groups. > and this makes it clear that you > don't give a damn about understanding my points and trying to address > the issues I see. Sorry if you feel that way. From where I sit you haven't ever bothered to enumerate the issues that you see. I've asked you repeatedly for a concrete example of how the proposed change would cause problems but you've always ignored the request. I haven't commented in detail on some of your proposed solutions because they solve the wrong problem. > Don't think I will continue this discussion, because I will not. > Sorry, but I reached my limit. Look, I'm not trying to offend you. I'm really trying to understand what you see as the issue with the proposed change? I've tried to address the many objections you have had to each of my points and I don't think I've left any of your explicit objections unanswered? I've also tried to explain why I don't think there is a general issue with SOC. It sounds like what you're really saying is that there may have been no real point to your objections and rather than admit this is so you're just going to end the discussion. That's fine, this has consumed far too much of my time as it is, but I really don't want to see the whole issue surface again when an implementation of the proposed changes hits CVS. > Find someone else for your problems. I don't have a problem, what I have is a potential solution for what I think might be a general problem... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
