Re: [xsl] xmlns in the root element prevents transformation

Subject: Re: [xsl] xmlns in the root element prevents transformation
From: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 24 Jul 2020 03:39:24 -0000
One can find questions and answers like this from so many people ...

https://stackoverflow.com/questions/5239685/xml-namespace-breaking-my-xpath/5
241062#5241062





On Thu, Jul 23, 2020 at 7:48 PM Debbie Lapeyre dalapeyre@xxxxxxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> 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@xxxxxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> escreveu no dia quinta,
> 23/07/2020 C (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@xxxxxxxxxxxxxxxx
> 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
> ================================================================

Current Thread