This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Fwd: phantom xmlns in xhtml [was: 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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]