Return-Path: 
 <cocoon-dev-return-13246-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 16373 invoked by uid 500); 11 May 2001 19:00:32 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 16089 invoked from network); 11 May 2001 18:59:40 -0000
Date: Fri, 11 May 2001 20:52:24 +0200 (CEST)
From: giacomo <giacomo@apache.org>
X-X-Sender: <giacomo@lap1.otego.com>
To: <cocoon-dev@xml.apache.org>
Subject: Re: [C2] <parameter> or <map:parameter> ?
In-Reply-To: <3AFBA72C.A2681AAC@anyware-tech.com>
Message-ID: <Pine.LNX.4.31.0105112025250.5234-100000@lap1.otego.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N



On Fri, 11 May 2001, Sylvain Wallez wrote:

>
>
> giacomo a =E9crit :
> >
> > On Thu, 10 May 2001, Sylvain Wallez wrote:
> >
> <snip/>
> > >
> > > Sorry for starting this hot thread, but I'm digging deeper and deeper=
 in
> > > C2, and when I don't understand something, I ask. Just tell me if I
> > > shouldn't...
> >
> > No problem :) go ahead if you like it hot :)
> >
> > Giacomo
> >
> Not that I particularly like hot discussions, but let me make a last
> try, since there is another point of view that make me think
> <map:parameter> is more consistent ;-)
>
> Some of you may find childish to discuss about "map:" which is only 4
> characters long, but the sitemap will be for most users the visible part
> of the Cocoon iceberg, and IMHO consistency is really important here.
>
> So, let's consider the following sitemap snippet :
>
>    <map:transformer name=3D"xslt"
> src=3D"org.apache.cocoon.transformation.TraxTransformer">
>     <use-store map:value=3D"true"/>
>     <use-request-parameters map:value=3D"false"/>
>     <use-browser-capabilities-db map:value=3D"false"/>
>    </map:transformer>
>
> In this snippet, the tag names "use-store", "use-request-parameters" and
> "use-browser..." are component-dependent and must conform to the
> configuration entry names awaited by TraxTransformer. But what is this
> "map:value" which belongs to the sitemap namespace ? Well, it's an
> equivalent notation for "<use-store>true</use-store>", which is also
> allowed by the sitemap.
>
> Now, we could imagine to also have an equivalent syntax for the
> configuration entry name similar to map:value, which could be
> <map:config name=3D"use-store"...> . And we obtain 4 semantically
> equivalent syntaxes (of which 2 are accepted today) which the sitemap
> will convert into the exact same Configuration for the component :
>
>   <use-store map:value=3D"true"/>
>   <use-store>true</use-store>
>   <map:config name=3D"use-store" value=3D"true"/>
>   <map:config name=3D"use-store">true</map:config>
>
> What is shown by the above is that the names of non-namespaced elements
> are component dependent, while the names of map-namespaced elements are
> sitemap dependent.
>
> Now consider this snippet :
>
>     <map:transform type=3D"sql">
>       <parameter name=3D"use-connection" value=3D"personnel"/>
>     </map:transform>
>
> What is important for the SQLTransformer is "use-connection", but not
> "parameter", which is used by the sitemap to build a Parameters object.
> Following the conclusions of the first snippet, the possible consistent
> syntaxes would be :
>
>   <use-connection map:value=3D"personnel"/>
>   <use-connection>personnel</use-connection>
>   <map:parameter name=3D"use-connection" value=3D"personnel"/>
>   <map:parameter name=3D"use-connection">personnel</map:parameter>
>
> And we end up with "parameter" belonging to the sitemap namespace...
>
> What do you think of this ? Should I start a vote on this subject ?

You are a PITA :) Ok, half way conviced. Will you shut if a vote is
agains your proposal :))

Giacomo


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org