Re: [docbook-apps] Docbook XSL and RELAX NG documents

[Matthew Burgess <matthew@linuxfromscratch.org>]

Mauritz Jeanson wrote:
>>-----Original Message-----
>>From: Matthew Burgess [mailto:matthew@linuxfromscratch.org] 
>>Sent: den 16 december 2004 21:19
>>To: Mauritz Jeanson
>>Cc: davep@dpawson.co.uk; 'Docbook-Apps'
>>Subject: Re: [docbook-apps] Docbook XSL and RELAX NG documents
>>
>>Mauritz Jeanson wrote:
>>
>>
>>>If you change to a "null namespace" in the template, then 
>>
>>things work
>>
>>>better. That is, change 
>>>
>>> <xsl:element name="{local-name(.)}"
>>>namespace="http://www.w3.org/1999/xhtml";>
>>>
>>>to 
>>> 
>>> <xsl:element name="{local-name(.)}" namespace="">
>>
>>Thanks for the suggestion, Mauritz.  Unfortunately that 
>>doesn't appear 
>>to have any effect whatsoever here :(
> 
> 
> 
> Hmm... This might have something to do with the processor. It works with
> Saxon, but I vaguely recall some issues with the implementation of
> node-set() in xsltproc.

Many thanks!  Indeed, saxon appears to get this right, where both 
xsltproc and xalan fail.

Sorry to pester you further, but I'm now getting a bunch of warnings:

XRef to nonexistent id: ch-scripts-console
Error: no ID for constraint linkend: ch-scatter-maillists.
XRef to nonexistent id: ch-scatter-maillists

I've a feeling this too is namespace related, as the "id" attribute is 
now namespace qualified, i.e. it's "xml:id".  Any ideas on solving this 
one?  I took a quick look at xhtml/xref.xsl but couldn't see an 
immediate way of fixing/hacking it.

I realise I may just be a victim of my own "jumping ahead of the gun" 
here, but I was simply after an idea of how the DocBook processing 
toolchains hold up with RELAX NG documents.  Obviously they don't seem 
to fair too well at the moment (just an observation, not a complaint!).

Thanks again,

Matt.