[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [Fwd: phantom xmlns in xhtml [was: DOCBOOK-APPS: xhtml customization]]
Go to bottom for more info on the phantom xmlns attributes in H? output for 1.60.1 xhtml. Search for //*** to skip background. Bob Stayton wrote: > On Thu, Jan 30, 2003 at 03:41:09PM -0500, ed nixon wrote: > <snip/> >>These items are kind of important to me because xmlns in H? and that one >>id attribute are parsed as invalid by both my Homesite validator and >>W3C. The cleanup and try-for-valid parameters don't seem to help. > > > Hmm, neither of these are actually produced by the > stylesheet! > > I looked at the template in xhtml/docbook.xsl, > and it is *not* generating an id attribute. If I process > a document with the xhtml stylesheet and xsltproc, I get an > id="generator" attribute in the <meta name="generator"> > output. But when I process it with Saxon, I don't get the > id attribute. I have to conclude that xsltproc is > volunteering that attribute, but I can't see why. > > The xmlns attribute is output at the discretion of > the processor. It should be able to put it just in > the document root element <HTML> without having to > repeat it all over the place. Older versions of > xsltproc put out a lot more than it needed, but later > versions don't. Saxon seems to do pretty well. > Perhaps if you upgrade your xsltproc it will be cleaner. > My apologies. I should have remembered being bitten by this one a couple of months ago. Here's the data on my xsltproc installation updated earlier today: //** Using libxml 20501, libxslt 10023 and libexslt 714 xsltproc was compiled against libxml 20428, libxslt 10024 and libexslt 715 libxslt 10023 was compiled against libxml 20428 libexslt 714 was compiled against libxml 20428 **// I'm not sure how recent it is but it's the latest available from the site that distributes the Win32 binaries. I'm stuck in that regard. As you suggested, the Saxon run produces much better output, valid output in fact. Thanks for that. However, I'm a bit confused and I wonder if xsltproc might be too. In looking into my phantom J? customization, I started sifting through the xhtml stylesheet directory. There are a number of files (among those that output H? elements in various modes) that have hardcoded xmlns attributes in the H? output. I'm speaking of 1.60.1. Are you saying that the processor should strip those hard coded attributes out if that's what it decides to do? Or are those xmlns attributes themselves an artifact of the "machine generation" of the xhtml stylesheets and therefore "bugs." If you want a list of the files that generate H? elemest, I can go beck and sift again. Stupidly I didn't make a note of them this PM. //*** Addendum to above for what it's worth: If you haven't read the above, my Win32 xsltproc xhtml output was failing W3C validation because of xmlns attributes inserted in the H? tags. On the other hand, Saxon produces valid output with the same input and driver file. For my own benefit, I did some bonehead slogging through the xhtml xsl directory of 1.60.1. just to get a general sense of things. I deleated the xmlns attribute in all the H? output related templates; the hypothesis was that xsltproc was passing them through to the output file without modification, and thus generating non-valid code (according to the W3C validator.) After the edit, I ran my driver stylesheet (avaiable on request) with xsltproc and checked the xhtml output. The xmlns attributes were back in the output again. I hope this is useful information for someone. Let me know what, if anything, happens. Thanks again to Bob for the help. ...edN
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC