Support #5254


Unexpected Empty Namespace Entry with XSL-FO & Inline SVG

Added by Dansker Dave over 2 years ago. Updated over 2 years ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


Hi there,

I'm getting an unexpected empty Namespace Entry with XSL-FO & Inline SVG.

I'm using Saxon HE 10.6 with openJdk 17 on Windows 10, 64-bit. The Test Output is from Windows, but it happens on our SUSE Enterprise Linux 11.1 Server too. (only entry on the Classpath for this Test was Saxon HE)

Please see attached Program & Output.

Here's an extract from the attached Output. What bothers me is the xmlns="" Attribute on the <g> Element.

<fo:instream-foreign-object content-type="image/svg+xml" content-width="272.6mm">
	<svg xmlns="" height="775" viewBox="0 0 1184 775" width="1184">
		<g xmlns="" style="fill-opacity:0;stroke-width:7;stroke:red">
			<rect height="99" width="254"/>

Surely, the <g> Element should inherit the Namespace from its <svg> parent?

All the best, Dave

Files (3.55 KB) Test Program Dansker Dave, 2022-01-30 14:00
SvgNamespaceOutput.txt (3.04 KB) SvgNamespaceOutput.txt Test Output Dansker Dave, 2022-01-30 14:12 (2.84 KB) StreamSource Version Dansker Dave, 2022-01-30 16:41
Actions #1

Updated by Michael Kay over 2 years ago

You're loading the stylesheet from a DOM. That's pointless and inefficient, but it should work. The reason it isn't working is that you haven't made the DOM namespace-aware.

You need to call factory.setNamespaceAware(true) on the DocumentBuilderFactory.

Better, though, is to load the stylesheet from a StreamSource or SAXSource.

Actions #2

Updated by Michael Kay over 2 years ago

  • Tracker changed from Bug to Support

Note, DOM has many frustrations, and one of them is that we're not actually able to examine the DOM and see that it's not namespace-aware, which means we can't even give you a decent error message for this case.

Actions #3

Updated by Dansker Dave over 2 years ago

Thanks for that, those are things that go right back to the dark ages when we started the project many, many moons ago.

I've tried to apply your StreamSource suggestion to the Test Program.
For what it's worth, I've attached the revised Program here.

It's actually considerably simpler now...
...and seems to work into the bargain. :-)

Actions #4

Updated by Michael Kay over 2 years ago

Personally I would do transformerFactory.newTemplates(new StreamSource(new StringReader(STYLESHEET)));

Cuts out the complexities of encoding the string as bytes and then decoding them again, with the consequent risk of confusion over what encoding is being used.

Michael Kay Saxonica

Actions #5

Updated by Dansker Dave over 2 years ago

Yes, of course.

Wouldn't it be a good idea if someone subclassed StreamSource as StringSource with a String constructor?

Actions #6

Updated by Michael Kay over 2 years ago

  • Status changed from New to Closed

I like the idea of subclassing StreamSource, however there is already a constructor new StreamSource(String) where the argument is a URI (SystemId) so this could be confusing.

Closing this with no further action.

Please register to edit this issue

Also available in: Atom PDF