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

Sadly, I can't find my first comment on the draft namespaces spec, which was to 
the effect of "this is horrible, but it hardly matters, because it's so 
horrible that no-one will use it". I was right on the first point, and very 
badly wrong on the second. 

Michael Kay
Saxonica

> On 24 Jul 2020, at 07:32, Damian Morris damian(_at_)moso(_dot_)com(_dot_)au 
> <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
>
> +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/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--