Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Extension elements and namespace prefixes
 XT doesn't support the extension element mechanism yet. The output handler isn't where you're supposed to handle extension elements. Even for output handlers, there is a bit of the problem here. An output handler should not be stripping of namespace prefixes; rather if it needs to recognize specific elements, it should be recognizing the expanded name (the namespace URI/local name pair) not the qualified name. At the moment do to this properly, it would have to process namespace declarations, which is not very convenient (and a waste since XT uses the expanded names internally, as any XSLT processor must). The HTML output handler doesn't, which means it doesn't always do the right thing. For example, <xsl:stylesheet xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"> <xsl:output method="html"/> <xsl:template match="/"> <html> <body> <p>An html br element: <br/>.</p> <p>Not at html br element: <br xmlns="http://www.jclark.com/not-html"/></p> </body> </html> </xsl:template> </xsl:stylesheet> will output <html> <body> <p>An html br element: <br>.</p> <p>Not at html br element: <br xmlns="http://www.jclark.com/not-html"> </p> </body> </html> This is wrong because the second br element should not be recognized as the HTML br element and so shouldn't get special treatment. I'll fix this somehow; I haven't decided how yet. Denys Duchier wrote: > > I have been playing with the new release of XT which I think is > wonderful (thank you James). While adapting my own output handler to > work with the new implementation I discovered a `problem' that had > escaped my attention before: > > the name of the element passed to methods startElement and > endElement contain the namespace prefix if it wasn't null. > > previously I always had a null prefix in such cases which is probably > why I never noticed the problem. The reason for passing a prefixed > name of course is that this is what is mandated by SAX. However it > seems to me that this doesn't make sense for extension elements since > the prefix is chosen by the stylesheet not by the implementation of > the extension. Thus a robust implementation must strip off the prefix > (btw, this is not done by XT's output handlers, which means that if > they are invoked with an arbitrary prefix they don't work - at least > the NXML output handler has this problem). At the moment, I simply > look for a `:' in order to strip a prefix if any. My question is: is > this the correct way to recognize a prefix? Is the namespace > separator guaranteed to always be a colon? XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
