docbook-apps message

Subject: [Fwd: phantom xmlns in xhtml [was: DOCBOOK-APPS: xhtml customization]]
From: ed nixon <ed.nixon@lynnparkplace.org>
To: docbook-apps@lists.oasis-open.org
Date: Fri, 31 Jan 2003 08:57:07 -0500
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