Joseph,
I was wondering if you could offer some advice for me.
I recently posted an enhancement request for xalan:write in xalan-c. It is supported in xalan-j, but it appears that nobody has gotten around to implementing it for xalan-c yet. Unfortunately I lack the c++ skills to implement this myself. I require this extension for a project I am working on at the moment, and its absence is a show-stopper for me. I appreciate that my urgency is not your urgency or the team's urgency, but I am in a situation now where due to the assumption that xalan:write would be in all both versions of xalan, I have made promises I cannot keep.
Can you offer any ideas for a solution to this seemingly intractable problem?
Best regards,
Curtis.
-----Original Message-----
From: Joseph Kesselman/CAM/Lotus [mailto:[EMAIL PROTECTED]]
Sent: 13 March 2002 14:22
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: auto formatting for xsl:output
>Is there a way to disable this formatting? I want it to be the same
>as the way I specified it.
The XML data model does not recognize any difference between <a></a> and
<a/>, so we have no way of knowing how you specified it originally.
It might be nice if there was a way to hint to the serializer that all
instances of a specific kind of element should be written out with a
separate end-tag even when empty. XSLT doesn't currently have a standard
mechanism for doing so, and I'm not sure it actually permits it in a
compliant processor. I suppose we could add a Xalan-specific option to
request this behavior... though of course if you ran the same stylesheet
elsewhere you'd get different results, which may not be what you want. It's
probably worth posting this into Bugzilla with Severity=Enhancement to
remind us to think about it when we have time to do so.
A least-impact, though less efficient, alternative would be to write a
separate postprocessor which finds the relevant shorthand <empty/> elements
and expands them into separate start/end tags.
"This communication is intended solely for the addressee and is confidential and not for third party unauthorised distribution."
