If you want to inject content that is visible within your processing
pipeline, but which doesn't disrupt other applications, then processing
instructions might do the job. Just don't try to nest them.
But elements (in an alien namespace) are probably a better solution, as
far as I can see from your description.
Michael Kay
Saxonica
On 15/12/2012 00:52, Dan Vint wrote:
I've come across an interesting problem that I'd like some ideas to
solve.
So I'm writing a series of XSLT stylesheets to convert s1000d issue
2.2 to issue 4. This content also has change markup that we want to
strip/resolve as we move forward. So I'm running a conversion sequence
like this:
1) Renumber/name the data modules and all links between them in the files
2) Resolve all change markup and strip.
3) Move from 2.2 to issue 3 and correct some tagging issues
4) Move from 3 to issue 4 changing the element and attribute names and
some structures that were reworked
I recently discovered that the authors did some things with the change
markup that I didn't expect (you say that never happens right ;-)) !.
So to aid the debugging and verifying that the stylesheet is not
introducing problems I have been trying to capture the "before" state
of the content in comments and then output the resolved results. So
content is marked for change with a specific <change> tag or many
elements have the same attributes to let you mark change on the
structural tags. So I can get some involved markup where entire
sections might be flagged to be deleted or modified and I'm trying to
copy that structure.
To copy the content I'm using <xsl:copy-of> which does the trick of
getting the current condition. I tried wrapping this in a comment with:
<xsl:comment>
<xsl:copy-of select="."/>
</xsl:copy-of>
That only got a comment with the text content of the element I was
copying - no markup. So I then tried this that worked:
<xsl:text disable-output-escaping="yes">
<!--
</xsl:text>
<xsl:copy-of select="."/>
<xsl:text disable-output-escaping="yes">
-->
</xsl:text>
This got the markup and all the contained content. But oh those
writers ;-), they also included their own comments in some of those
elements. So when I tried processing these results in the next step I
got errors about nesting comments inside comments.
So my next thought was to wrap this information inside a CDATA section
with similar constructs:
<xsl:text disable-output-escaping="yes">
<![CDATA[
</xsl:text>
<xsl:copy-of select="."/>
<xsl:text disable-output-escaping="yes">
]]>
</xsl:text>
This worked great for this stage, but I found after the next
processing step that those CDATA sections were unwrapped and the
text/markup that was escaped was left in place.
I would like to be able to push these files through all the steps and
have the intermediate results available for troubleshooting - that was
my goal. It looks like I'm going to have to have the files
reviewed/cleaned up by hand immediately following the removal of the
change markup and then after the files are clean, then continue
processing. That forces the team to have to touch the files twice.
As I'm writing this up, maybe what I need to do is to wrap CDATA
sections inside CDATA sections. Such that there are enough wrappings
to allow the last stage to still have one level of wrapping left. Not
sure if it is legal, but it is an idea to work around the problem. The
writers/conversion team will not see the multiple wrappings unless
they (more likely me) have to go back to trace down a problem.
The only other way I can see how to do this is to not to use a fully
aware XML processing method - but I have all these stylesheets
completed except for this last minute problem. Another possibility
would be to push the change markup removal to the last step. It would
mean rewriting that stylesheet to deal with the new issue 4 elements,
but that would also work.
Anyone have ideas for an alternate solution?
---------------------------------------------------------------------------
Danny Vint
Panoramic Photography
http://www.dvint.com
voice: 619-938-3610
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--