On Fri, 2019-04-26 at 16:17 +0200, Christophe Marchand wrote:
[...]
So, I'd like to declare namespaces strings as constants, and use
these constants in XSL.
The only way I've found is to declare a DTD with entities, one
entity per namespace :
Then, use this DTD in my XSL :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:stylesheet SYSTEM "../../namespaces.dtd">
<xsl:stylesheet
xmlns:xf="&nsXF;"
xmlns:added="&nsAdded;" ...>
You could instead write,
<!DOCTYPE xsl:stylesheet [
<!ENTITY % nsdecl SYSTEM "../../namespaces.dtd">
%nsdecl;
]>
at the start of your document, but the way you did it seems cleaner.
You could make #FIXED attributes for xsl:stylesheet that insert the
declarations automatically, although that would probably require that
the XSLT processor perform DTD validation, and DTD-validation for XSLT
stylesheets might end up being an ongoing maintenance burden because of
direct element constructors & extension attributes.
Am I the only guy to do this ?
Is it a good practise ?
You are not alone and it’s p perfectly fine thing to do.
It might be worth asking why you need so many namespaces. Can you
combine some of them? You could hav an XSLT stylesheet that did this
and even call it from XSLT with fn:transform() if needed, in a library
function.
It’s also possible, at least in principle, to remove the namespaces and
make a “flattened” document, possibly even with “standard” prefixes so
you end up with <els-esclave> instead of Els:esclaeve, or whatever, and
split them out again at the end of procesing. What such techniques do
is they move the complexity from one place to another. It’s a trade-
off.
XSLT 2 and 3, XPath 3, XQuery 3, all have features for making using
namespaces a little easier, e.g. EQNames and wildcards, so i’d keep the
namespaces there and i thinkyou’ve made a sensible design choice.
Liam
