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

+1 for my first question to support requests being to check the usage of 
namespaces, as this is where 80%+ of my users' problems are. +1 for the 
3-minute fix being the most common outcome, too!

I do think that namespaces are where XML derives an enormous amount of its 
power from, though, and wouldn’t lose them. I also don’t have any good 
suggestions for how to improve the situation, other than to repeat the obvious 
advice that making the simple things simple is critical, and that this often 
involves having sensible defaults.

Cheers,

Damian

--

MOSO Xmplify XML Editor - Xmplary XML for Mac OS X

w: http://xmplifyapp.com
t: @xmplify



> On 24 Jul 2020, at 12:48 pm, Debbie Lapeyre 
> dalapeyre(_at_)mulberrytech(_dot_)com 
> <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_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
> ================================================================
> --~----------------------------------------------------------------
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
> EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1106500
> or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
> --~--