When you try to explain this to beginners. they
do not believe you. 'But who would do that?' they cry.
If I had a nickle for every time I as a consultant have
been called to solve a horrible mess, checked the namespaces,
fixed them, went home in 3 minutes ... And many of you on
this list have done this far more often than I.
Namespaces are a real problem.
But thank you for working on those error messages Michael.
--Debbie
On Jul 23, 2020, at 6:17 PM, Michael Kay mike(_at_)saxonica(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Failing to appreciate the implications of a namespace declaratoin in the
source document is probably the most common source of XSLT questions on
StackOverflow - if you search there for "XSLT default namespace" you will
find at least 600 questions from people who have fallen into this trap.
It's particularly invidious beccause (a) the symptoms of the failure are
usually wrong results rather than any kind of error, and there's nothing in
the wrong results that hints at a namespace problem, and (b) many people
try to pick up XSLT from very elementary tutorials that only handle the
simplest of constructs, and leave out any discussion of namespaces as if
they are somehow an advanced feature that you don't need to worry about
until later.
It's also invidious because although the problem was recognised very
early on, it's proved impossible to fix without creating backwards
compability problems. The xpath-default-namespace attribute in XSLT 2.0
helps, but only if you know what the problem is and know that you need to
use it. In Saxon I've been experimenting with another solution, which is
for bare unqualified names in the stylesheet to match elements in any
namespace or none - but for conformance reasons, that option can't be the
default, so beginners still fall straight into the trap. I've also tried
heuristics that attempt to detect when users are falling into the trap
(specifically, when a namespace is used in the source document and isn't
declared in the stylesheet) but I fear that users who don't even know that
these peculiar xmlns things are called namespaces find the message
incomprehensible and ignore it.
If the source document has a namespace declaration then it changes the
names of the elements, and if your stylesheet is trying to match elements
by name then they won't match unless you get the namespace right. So
understanding this is absolutely fundamental.
Michael Kay
Saxonica
On 23 Jul 2020, at 21:55, Manuel Souto Pico
terminolator(_at_)gmail(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
I think I can answer myself.
The stylesheet needs to have the version hardcoded in the root element,
at least from what I can tell, like
xpath-default-namespace="urn:oasis:names:tc:xliff:document:1.2", and it
must be the same version as the input XML files.
Cheers, Manuel
Manuel Souto Pico <terminolator(_at_)gmail(_dot_)com> escreveu no dia
quinta,
23/07/2020 à(s) 21:11:
Dear all,
This transformation gives me an empty output file:
https://xsltfiddle.liberty-development.net/gVhEaiQ
However, if I remove the xmlns="urn:oasis:names:tc:xliff:document:1.2
bit from the XLIFF root node, then it works.
Could somebody help me understand why that happens?
Thanks in advance.
Cheers, Manuel
XSL-List info and archive
EasyUnsubscribe (by email)
XSL-List info and archive
EasyUnsubscribe (by email)
================================================================
Deborah A Lapeyre mailto:dalapeyre(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Phone: 301-315-9631 (USA)
Suite 207 Fax: 301-315-8385
Rockville, MD 20850
----------------------------------------------------------------
Mulberry Technologies: Consultancy for XML, XSLT, and Schematron
================================================================