Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 38407 invoked from network); 8 Feb 2001 02:24:08 -0000 Received: from fw.infoplanning.net (HELO infoplanning.com) (@209.8.58.131) by h31.sny.collab.net with SMTP; 8 Feb 2001 02:24:08 -0000 Received: (qmail 29606 invoked from network); 8 Feb 2001 02:37:05 -0000 Received: from 3ff8cf5d.dsl.flashcom.net (HELO sound) (63.248.207.93) by inet with SMTP; 8 Feb 2001 02:37:05 -0000 Message-ID: <000b01c09175$ff1a78e0$3200a8c0@calvary.org> From: "Berin Loritsch" To: References: Subject: Re: Standardizing XSP Namespaces Date: Wed, 7 Feb 2001 21:21:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > i'd almost concur, but on the xsp-dev list, matt requested a move to a > cocoon-agnostic namespace for shared xsp logicsheets (he has an impl of > esql and is discussing doing some others). on the one hand, he's got a > point, maybe something like this would be better: > > http://apache.org/xsp/sendmail/v1 Point taken, and I like that style of URL. Short, simple, generic, and has versioning. Some of these things will not change much after they are defined, so we should be good. > on the other hand, i'd hate to make people change namespaces again. boy, > it sure seems like the namespace working group could have antipicated this > problem and written in some support for namespace migration... well, c'e > la vie. anyway, i have no strong opinion one way or the other, so i'd let > people vote. do we stick with this scheme > > http://apache.org/cocoon/sendmail/v1 +0 -- Not opposed, but don't want to cause too much rework > > or generalize to > > http://apache.org/xsp/sendmail/v1 +1 -- To me, this is preferred. > > After dependancies on prefixes are resolved, the expected > > results should be that if the stylesheet creates elements, > > they should belong to the associated namespace, using the > > default prefix. > > i will love you forever when you remove the dependencies on namespace > prefixes. I am convinced this is going to take some rewriting of the XSP engine in Cocoon 2. My take on this is that we need the prefixes specified in the configuration still. 1) When the URI is encountered, the logicsheet is run. 2) When the logicsheet creates elements associated with the URI, it uses the prefix specified in the configuration engine. 3) We don't need to overspecify the namespaces, all it does is eat up precious processing power.