[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: xmlns in the root element prevents transformation
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 > ================================================================
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|