Return-Path: <stefano@apache.org>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 7454 invoked from network); 7 May 2000 22:03:57 -0000
Received: from pop.systemy.it (194.20.140.28)
  by locus.apache.org with SMTP; 7 May 2000 22:03:57 -0000
Received: from apache.org (pv26-pri.systemy.it [194.21.255.26]) by
 pop.systemy.it (8.8.8/8.8.3) with ESMTP id AAA28798 for
 <cocoon-dev@xml.apache.org>; Mon, 8 May 2000 00:03:53 +0200
Message-ID: <3915E8AE.37949DCE@apache.org>
Date: Mon, 08 May 2000 00:05:34 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en,it
MIME-Version: 1.0
To: Cocoon <cocoon-dev@xml.apache.org>
Subject: Re: Preserving namespaces in XSP
References: <20000507044207.34771.qmail@locus.apache.org>
 <3915451D.A7705BE3@apache.org> <0005071214270C.01284@ricardo>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

[let me comment the namespace approach now]

Ricardo Rocha wrote:
> Caramba! I know this mechanism may look kinda kludgy, but let's
> take the following into consideration:
> 
> Namespace usage in XSP is typically associated with logicsheet
> activation (1).
> 
> Most logicsheets declare only their own namespace as well as
> that of XSP.
> 
> During XSP code generation, one or more selected logicsheets
> are applied in turn to transform the input XSP document into an
> equivalent source program.
> 
> As each logicsheet is applied, those namespaces not explicitly
> declared in it are _not_ preserved in the [intermediate] resulting
> document.
> 
> Briefly stated, "xmlns:" attributes are not copied by XSLT unless
> they correspond to a namespace declared at the stylesheet root
> element level.
> 
> To avoid this, one would need to declare all namespaces in all
> logicsheets!

I'm sorry, but I don't understand this, can you elaborate more?
 
> In many cases namespaces used for logicsheets need not be
> preserved on output, as their dynamic tags are typically
> substituted by Java expressions rather than by markup.

and this makes perfect sense, the case is where I want something like
this

<a xmlns:a="A">
 <a:a>
  <xsp:logic>
   if (whatever) {
     <a:b/>
   }
  </xsp:logic>
 </a:a>
</a>

that should turn out, if "whatever" is true as

<a xmlns:a="A">
 <a:a>
  <a:b/>
 </a:a>
</a>

rather than

<a>
 <a>
  <b/>
 </a>
</a>

as it happened before.

The syntax above is the one I'd like to see, but I'm sure you have valid
points for proposing an alternative one.

> For those cases where the result of dynamic tag expansion _is_
> a set of one or more namespace-qualified elements, preserving
> namespace becomes a necessity.

right
 
> So far, XSP would silently drop namespace prefixes forcing
> stylesheet templates to match _non-qualified_ elements only.
> While this works in most cases, it also impairs the usefulness
> of namespaces: the resulting element names may well clash
> with unrelated, "synonymous" elements...

yep, this is what happens above...
 
> Thus, a mechanism is needed to selectively preserve
> namespaces in XSP documents. "Selectively" here means
> that namespaces declared only for logicsheet processing
> should not be preserved in the output document.

yes
 
> The strategy chosen for this is to "reuse" the "xsp:" prefix
> (not used at all for attributes in XSP) to preserve namespaces
> dropped by logicsheet processing.
> 
> Thus, for example, if logicsheet "xsql.xsl" uses namespace
> "xsql:" for both dynamic and result tags, the following XSP
> page illustrates how to preserve the namespace:
> 
>   <?cocoon-process type="xsp"?>
>   <?xml-logicsheet href="xsql.xsl"?>
>   <?cocoon-process type="xslt"?>
>   <?xml-stylesheet href="page.xsl" type="text/xsl"?>
>   <xsp:page
>     language="java"
>     xmlns:xsql="http://www.plenix.org/xsp/xsql"
>     xmlns:xsp="http://www.apache.org/1999/XSP/Core"
>   >
>     <-- Namespace preserved here -->
>     <page xsp:xsql="http://www.plenix.org/xsp/xsql">
>       <title>Employee List<title>
>       <xsql:execute-query id="demo" use-connection="scott">
>         <xsql:statement>
>           SELECT      ename, job, sal
>           FROM        emp
>           ORDER BY ename
>         </xsql:statement>
>       </xsql:execute-query>
>     </page>
>   </xsp:page>
> 
> Upon execution, this XSP page would yield:
> 
>   <page xmlns:xsql="http://www.plenix.org/xsp/xsql">
>     <title>Employee List</title>
>     <xsql:rowset id="demo">
>       <xsql:row sequence="1">
>         <ename>ADAMS</ename>
>         <job>CLERK</job>
>         <sal>1100</sal>
>       </xsql:row>
>       .  .  .
>     </xsql:rowset>
>   </page>
> 
> which could then be processed by an XSLT template like:
> 
>   <xsl:template match="xsql:rowset[@id = 'demo']">
>     <center>
>       <table border="1">
>         <tr>
>           <th>Name</th>
>           <th>Jon</th>
>           <th>Salary</th>
>         </tr>
>         <xsl:for-each select="xsql:row">
>           <tr>
>             <td><xsl:value-of select="ename"/></td>
>             <td><xsl:value-of select="job"/></td>
>             <td align="right"><xsl:value-of select="sal"/></td>
>           </tr>
>         </xsl:for-each>
>       </table>
>     </center>
>   </xsl:template>
> ===============================================================
> (1) Btw, let's recall that logicsheets can now be explicitly declared by means
>      of  the <?xml-logicsheet?> pi and are no longer tied to namespaces

I have some comments:

1) your solution imposes us to avoid future use of attributes with the
"xsp:" namespace. Since I think that namespaced attributes may play a
very important role in the future (just like, for example, XLink which
uses namespaced attributes rather than elements to signify linking), you
solution may require changes in the future.

2) the solution is not trivial to understand because it uses the "xsp:"
attribute as a 'twisted' "xmlns:" prefix, which, I recall, it's not a
namespace but a prefix declared by the XML-Namespace specification.

3) people that use normal namespace syntax in content still have
problems.

4) you addressing another need I didn't thought to address, but you are
right considering it: the use of namespace addiction to taglib generated
markup. Your example

>   <page xmlns:xsql="http://www.plenix.org/xsp/xsql">
>     <title>Employee List</title>
>     <xsql:rowset id="demo">
>       <xsql:row sequence="1">
>         <ename>ADAMS</ename>
>         <job>CLERK</job>
>         <sal>1100</sal>
>       </xsql:row>
>       .  .  .
>     </xsql:rowset>
>   </page>

may create troubles since you use the "xsql" namespace for the
"container" tags (rowset and row), while you use the default namespace
for the tuple elements.

Now, while this makes sense on some namespace contexts, it's generally
faulty to consider such a practice a generally useful one.

Either you do:

   <page xmlns:xsql="http://www.plenix.org/xsp/xsql">
     <title>Employee List</title>
     <xsql:rowset id="demo">
       <xsql:row sequence="1">
         <xsql:ename>ADAMS</xsql:ename>
         <xsql:job>CLERK</xsql:job>
         <xsql:sal>1100</xsql:sal>
       </xsql:row>
       .  .  .
     </xsql:rowset>
   </page>

or more structured

   <page xmlns:xsql="http://www.plenix.org/xsp/xsql">
     <title>Employee List</title>
     <xsql:rowset id="demo">
       <xsql:row sequence="1" xmlns:tuple="urn:my-database:emp">
         <tuple:ename>ADAMS</tuple:ename>
         <tuple:job>CLERK</tuple:job>
         <tuple:sal>1100</tuple:sal>
       </xsql:row>
       .  .  .
     </xsql:rowset>
   </page>

The question is: is it responsibility of XSP to provide a way to
"overload" a taglib-generated content setting a namespace for it, or it
is the taglib responsibility?

My opinion is that XSP shoud provide namespace-overloading capabilities
on a taglib-wrapping scale, while taglibs should be able to mess around
with their namespaces as they please.

The problem comes when taglibs use a namespace for some of their
generated markup and we have wrapped them with XSP namespace semantics.
In general, namespaces are not composable and we should not try (IMO) to
move in this direction...

So I propose something like this:

   <?cocoon-process type="xsp"?>
   <?xml-logicsheet href="xsql.xsl"?>

   <xsp:page
     language="java"
     xmlns:xsql="http://www.plenix.org/xsp/xsql"
     xmlns:xsp="http://www.apache.org/1999/XSP/Core"
   >

   <page:page xmlns:page="http://xml.apache.org/cocoon/page">
     <page:title>Employee List<page:title>
     <xsp:namespace prefix="xsql" uri="http://www.plenix.org/xsp/xsql">
      <xsql:execute-query id="demo" use-connection="scott">
       <xsql:statement>
         SELECT      ename, job, sal
         FROM        emp
         ORDER BY ename
       </xsql:statement>
      </xsql:execute-query>
     </xsp:namespace>
   </page:page>
  </xsp:page>

which should be expanded into

   <page:page xmlns:page="http://xml.apache.org/cocoon/page">
     <page:title>Employee List</page:title>
     <xsql:rowset id="demo" xmlns:xsql="http://www.plenix.org/xsp/xsql">
       <xsql:row sequence="1" xmlns:tuple="urn:my-database:emp">
         <tuple:ename>ADAMS</tuple:ename>
         <tuple:job>CLERK</tuple:job>
         <tuple:sal>1100</tuple:sal>
       </xsql:row>
       .  .  .
     </xsql:rowset>
   </page>

Note two things:

1) namespaces declared for static markup are simply copied over. Their
xmlns: declaration position doesn't matter as long as namespaces are
preserved in their existing meanings.

2) the <xsp:namespace ...> element should allow us to impose a
particular namespace to the logic-generated markup in general (being
taglib or any other kind of XSP machinery), but only if the generated
markup doesn't have a specified namespace. Also, as for the namespace
specification, attributes of the dynamically-generated markup should not
be touched.

I have no idea how hard this is to implement, but this is how I picture
namespaces support for XSP-next (which I would call XSP 1.1)

Namespaces are another of those things JSP simply ignore and will
continue to do so for (most probably) another year. 

XML newbies usually don't understand namespaces and why namespaces are
the most elegant and powerful part of the XML model as a whole. But as
soon as they do, there will be requirement for solutions that are
-built- around the multi-dimensionality of namespaced-xml, rather than
simply using an SGML subset.

Ok, people, let's sort this out since taglibs and namespaces will be the
base for the new XSP 1.1 specification.

And I want this in place for Cocoon2 before October, so let's think
about it now and sent your comments/proposals/solutions ASAP. thanks.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------