[oXygen-user] Help needed with XSLT
Reaves, Timothy
Thu Jun 23 13:37:51 CDT 2011
Thanks for the response.
1. Is there a particular XSL list you refer to?
2. In our application, we process hundreds of thousands of SVG images.
Individual teams are responsible for providing an stylesheet that produces a
'cleaned' SVG; this is for space savings (we're talking on the order of 100
GB here, so a 50% reduction is a big deal). To know that their stylesheets
have not 'broken' the SVG, the publishing process has an in-bult check for
well-formedness, and validates against the SVG spec; those attributes do not
prevent rendering, but they do prevent validation. Which means we can not
check that other errors are not present.
3. We use Saxon-EE, as that is what oXygen uses, and we wanted to deploy
with the same. So we've licensed Saxon.
4. Ya, I originally had the SVG as an element, but that caused me some other
grief I can't remember.
5. I'm not an XSLT programmer, so this is not surprising, even though it is
unfortunate. All I can do is try something, see if it has a positive result
(makes my output more like I want it), and go from there. I'll study your
changes, and try to incorporate them.
Thanks!
On Thu, Jun 23, 2011 at 2:16 PM, Syd Bauman <> wrote:
> 1) This is probably more appropriate for the XSL-list than here. You
> would likely find that if you followed the (stringent) posting
> guidelines for that list, you'd have your answer before you post.
> At least, I usually do :-)
>
> 2) Out of curiosity, why do you care? There is really no harm done
> having extra namespace declarations on the SVG root element, is
> there? (I agree it is ugly as sin, and often run the output of my
> transforms through an editing step to strip 'em off:
> $ saxon style.xslt in.xml | perl -pe 's, xmlns:duck="
> http://www.example.org/ns/",,;' > out.xml
>
> 3) What processor are you using?
>
> 4) I can take a crack at reducing the namespace declarations on the
> output <svg> node by making it an explicit literal result element
> instead of using <copy>. The i prefix is still there, though. (I
> presume because it's tested for in the code). See below.
>
> 5) This strikes me as very non-XSLT-like code, and very inefficient.
> (You are testing every attribute, comment, or processing
> instruction to see if it is in the sequence of every metadata,
> switch, etc.)
>
> Here is a rewrite that takes care of all but 1 extra namespace, and I
> think does the same job in a clearer and more efficient manner:
>
> ---------
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl"
> xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/"
> xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/"
> xmlns:graph="http://ns.adobe.com/Graphs/1.0/"
> xmlns:x="http://ns.adobe.com/Extensibility/1.0/"
> exclude-result-prefixes="xs xd a x graph"
> xpath-default-namespace="http://www.w3.org/2000/svg"
> version="2.0">
>
> <xsl:template match="/">
> <svg xmlns="http://www.w3.org/2000/svg">
> <xsl:apply-templates select="svg/*"/>
> </svg>
> </xsl:template>
>
> <xsl:template match="*">
> <xsl:copy>
> <xsl:apply-templates select="@*|node()"/>
> </xsl:copy>
> </xsl:template>
> <xsl:template match="comment()|processing-instruction()|text()">
> <xsl:copy/>
> </xsl:template>
> <xsl:template match="@*">
> <xsl:if test="namespace-uri() ne
> 'http://ns.adobe.com/AdobeIllustrator/10.0/'">
> <xsl:copy/>
> </xsl:if>
> </xsl:template>
>
> <xsl:template match="i:pgf | metadata | foreignObject"/>
>
> <xsl:template match="switch">
> <xsl:apply-templates select="node()"/>
> </xsl:template>
>
> </xsl:stylesheet>
> ---------
>
> HTH.
>
> > I'm applying a transform to SVG documents, to make them validate
> > against the SVG RNG schema. I have everything working EXCEPT the
> > name spaces on the SVG element itself. These SVG documents where
> > edited in Adobe Illistrator, and the original SVG element is:
> >
> > <svg xmlns="http://www.w3.org/2000/svg" xmlns:a="
> > http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/" xmlns:graph="
> > http://ns.adobe.com/Graphs/1.0/" xmlns:i="
> > http://ns.adobe.com/AdobeIllustrator/10.0/" xmlns:x="
> > http://ns.adobe.com/Extensibility/1.0/" xmlns:xlink="
> > http://www.w3.org/1999/xlink">
> >
> > and what I want is:
> >
> > <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="
> > http://www.w3.org/1999/xlink">
> >
> > The stylesheet starts:
> > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl"
> > xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/"
> > xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/"
> > xmlns:graph="http://ns.adobe.com/Graphs/1.0/"
> > xmlns:x="http://ns.adobe.com/Extensibility/1.0/"
> > exclude-result-prefixes="xs xd a x graph"
> > xpath-default-namespace="http://www.w3.org/2000/svg"
> > version="2.0">
> >
> > My understanding is that 'exclude-result-prefixes="xs xd a x
> > graph"' should not copy over the namespaces identified, but a, x,
> > and graph are still there in the output. My main template is below,
> > and it keeps the namespace & extensions off of the child elements
> > of SVG, just not the SVG node itself.
> >
> > <xsl:template match="@*|node()">
> > <xsl:choose>
> > <xsl:when test=". = //i:pgf"/> <!-- This is the BLOB -->
> > <xsl:when test=". = //@i:*" /> <!-- These three are all of the
> > Adobe extensions -->
> > <xsl:when test=". = //metadata"/>
> > <xsl:when test=". = //foreignObject"/>
> > <xsl:when test=". = //switch"> <!-- We do not want the switch
> > elements, just their text nodes. -->
> > <xsl:apply-templates select="node()"/>
> > </xsl:when>
> > <xsl:otherwise>
> > <xsl:copy>
> > <xsl:apply-templates select="@*|node()"/>
> > </xsl:copy>
> > </xsl:otherwise>
> > </xsl:choose>
> > </xsl:template>
> >
> > Any ideas?
> _______________________________________________
> oXygen-user mailing list
>
> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.oxygenxml.com/pipermail/oxygen-user/attachments/20110623/ce6481eb/attachment.html
More information about the oXygen-user
mailing list