cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: defaulting to a matcher when another one is not present
Date Tue, 15 Oct 2002 17:59:45 GMT
>> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message