Re: Namespaces in XSP (was Fwd: Propose a fix, discuss the way I've done that)

[Robin Green <gr...@hotmail.com>]

This discussion should be taking place openly on cocoon-dev, so I'm posting 
it there.

"Tagunov Anthony" <at...@nnt.ru> wrote:
>==================BEGIN FORWARDED MESSAGE==================
> >From: "Tagunov Anthony" <at...@nnt.ru>
> >To: "ricardo@apache.org" <ri...@apache.org>
> >Date: Thu, 07 Sep 2000 18:25:54 +0400
> >Reply-To: "Tagunov Anthony" <at...@nnt.ru>
> >Priority: Normal
> >X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT 
>(4.0.1381;6)
> >MIME-Version: 1.0
> >Content-Type: multipart/mixed; 
>boundary="_=_=_=IMA.BOUNDARY.G0ITF6138764=_=_=_"
> >Subject: Propose a fix, discuss the way I've done that
> >
>
>Hello, Ricardo!
>
>I'm a realtively new person to Cocoon, but I think it's a fabulous project, 
>just what I've dreamed of while I was getting in touch with XSLT specs..
>We here are now reserching the possibility of using it as backbone for our 
>new and existing wap and web projects and hence I'me extensively exploring 
>it's possibilities
>and
>writing a model application to show to our department how things can be 
>done with Cocoon.
>
>Ricardo, plz, will you take a look at what I've done to xsp-java.xsl for my 
>installation (here's a cvs diff) and tell me what you think of it.
>
>-----------------------------------------------------------------chapter 1
>The reason that drove me to go for it may be seen if use the following .xml 
>and .xsl files I'm attaching as well, they demonstrate a problem I've hit 
>quity clearly:
>   plz compare what you see with one.0.xml, and one.2.xml ... the uri's are 
>actually missing!  I hit this problem already a while ago, when I was 
>writing my own processor
>deriving it from the xinclude processor code -- and the problem I hit was 
>that at
>  .xml--(xsp processor)----->.----(my processor)----->  I was unable to 
>catch my own attributes of the form  <..  xecute:href=  ..> (as with 
>xinclude:href=  )

Yes, outputting namespaces is a known problem in XSP. The workaround in 
1.7.4 is to replace all namespace declarations that you wanted passed 
through to the XSP output with xsp:blah instead of xmlns:blah. Obviously 
this is not very satisfactory because it is non-standard, but it seems to 
work for me.

The problem, as far as I can tell, stems from the fact that the XSLT spec 
says, and I quote: "The built-in template rule for namespace nodes is also 
to do nothing. There is NO PATTERN [my emphasis] that can match a namespace 
node; so, the built-in template rule is the only template rule that is 
applied for namespace nodes."

I think this is a stupid rule. But anyway, we have to live with it now - 
it's the spec, and what they spec says goes. So xsp-java.xsl cannot directly 
find out where the xlmns: declarations are. In 1.7.4 as I just said the 
workaround is to replace xmlns: with xsp:

Ricardo and I have each proposed a different way of doing this for 1.8, and 
it looks like you may have found a third.

My proposal is very simple: Replace xmlns: with xsp: in 
XSPJavaPreprocessor.java, which is Java not XSLT so it can see the xmlns: 
declarations.

Ricardo's solution, currently in 1.8-dev in CVS, appears to put a xmlns: 
attribute on every single element in the scope of a namespace, by matching 
on the namespace axis (not the same thing as matching on namespace 
declarations [called "namespace nodes" in the spec], which according to the 
spec should be impossible). This works but is inefficient. I prefer my 
solution of course. :-)

>while at
>  .xml--(my processor)--> it worked fine. I guess that with current 
>xsp-java.xml even .xml---(xsp)--->.---(xinclude)---> transform will fail 
>(in fact it does)
>While debugging my processor I did a debug printout or 
>Node.getNamesapceURI()'s from all the nodes I was scanning -- and I found 
>that for
>.xml--(my processor)--> all the URI's we in place, while for  
>.xml--(xsp)-->.--(my processor)--> all we missing.

Right, that's what I found too.

>  I wrote a letter to cocoon-request,

What's cocooon-request? I've never heard of it. You should subscribe to 
cocoon-users and/or cocoon-dev, and post messages to them.

>but nobody answered,
>I was stuck and didn't know what to do untill yesterday (as the matter of 
>fact I made my processor ignore URI's and rely only on the names what I 
>call a dirty hack),
>
>but yesterday it seems to my I've found a way to overcome this, see the 
>patch.
>
>The patched templates for match="*" and match="@*" work fine with xpath 
>namespace-uri(.) function, and
>facilities for providing corrent URI's with
>
>xsp:element and xsp:attribute also work fairly good.
>
>-------------------------------------------------------------------chapter 
>2
>
>Examples:
>ex 1================================
><xsp:page..>
>   <page xmlns:one="http://..one">
>      <one:a one:b/>
>================================works fine (see one.1.xml with the patched 
>version of xsp-java.xsl)
>
>ex 2================================
><xsp:page..>
>   <page xmlns:one="http://..one">
>     <xsp:element name="one:a" namespace="http://..">
>     <xsp:attribute name="one:a" namespace="http://..">
>================================works fine (it is imitation of xsl:element 
>and xsl:attribute.., see one.3.xml for examples)
>
>
>ex 3================================
><xsp:page..>
>   <page xmlns:one="http://..one">
>     <xsp:element name="one:a"..>
>     <xsp:attribute name="one:a"..>
>================================also work fairly good, the one: prefix gets 
>resolved by an xpath expression operating on the source xsp file (see 
>diff).
>Trouble 1: if no URI has been found createElementNS("","one:a") code gets 
>generated which causes a trap at execution time, smth on DOM error which is 
>not
>                  very descriptive and doesn't help the writer to correct 
>his error

I don't see the point of xsp:element at all (anywhere, not just here). Why 
don't you use xsl:element or just create a literal element instead? Both 
will give you better error messages if you forget to declare the namespace.

>
>Trouble 2:
>ex 4================================
><xsp:page..>
>  <page xmlns:xmlns="http://.one">
>   <xsp:element name="a"/>
>   <xsp:element name="a" namespace="http://..."/>
>================================do not work at all. The code that's 
>generated looks okay from my point of view (I do not see the error), it 
>looks like
>    ..createElementNS("http://..","a");
>    ..createElementNS("http://..","a");
>That is the defalult namespace gets resolved by my xsl patch all right but 
>when we make a createElementNS("smth","not-prefixed-name") call then the 
>generated at
>run-time element doesn't seem to have a namespace URI assosiated with it (I 
>haven't checked it with my processor that prints out getNamespaceURI() but
>show-namespaces.xsl attached here sais that namespace-uri(.) is an empty 
>string.

Well, this is beyond my expertise - I know little about namespaces.

>The same thing happens with <dummy xmlns:xmlns="http://.."><xsp:element 
>name="a">..  (defaut namespace in effect)
>                                                  <xsp:element name="a" 
>namespace="http://...">..                 (no prefix given, but there is an 
>explicit namespace attribute)

If you try all these by using normal XML notation instead of xsp:element 
using 1.8-dev, do they all work?

>----------------------------------------------------------------chapter 3
>All these cases you may find in one.2.xml and one.3.xml (they are a little 
>bit commented there.)
>
>Notion 1: I've also written xsl code to avoid calling 
>createElementNS("","xmlns:xmlns","http://) for construction
><xsp:attribute name="xmlns:xxx">http://...</xsp:attribute>
>
>----------------------------------------------------------------coclusion
>Conclusion: although this code has got some trouble with the case when a 
>namespace URI is either retrived (a default namespace is in scope) or 
>explicitely given
>and the name has got no prefix in all other cases it looks to work smooth 
>and fixes trouble with MANY things including running XSLT transforms that
>treat elements from user namespaces propelly, running XInclude processor, 
>running custorm processors...
>
>Your opinion?

I don't really understand your patch, but it seems to be very 
over-complicated for the task I'm afraid. Try downloading 1.8-dev from 
http://xml.apache.org/from-cvs and try it, using normal XML notation not 
xsp:element (which is useless IMHO and should not be used). Does it meet all 
your requirements?

>
>----------------------------------------------------------------
>Question 1: what is the following code for? It looks like it is stripping 
>xsp: from attributes, I guess this has been done for some purpose..
>
>   <xsl:template match="@*">
>     ..
>     <xsl:choose>
>       <xsl:when test="starts-with(name(.), 'xsp:')">

See start of my reply above. It is the hacky workaround in 1.7.4.


_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.