[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xmlns in the root element prevents transformation

Subject: Re: xmlns in the root element prevents transformation
From: "Damian Morris damian@xxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 24 Jul 2020 07:43:05 -0000
Re:  xmlns in the root element prevents transformation
Ha! :)

I will say that XPath not having support for default namespaces was, perhaps,
with the benefit of hindsight and in retrospect, without casting aspersions
and with all the best will in the world, looking backwards for just a moment,
as an aside and just to shoot the breeze for a minute, a mistake :)



On 24 Jul 2020, at 4:54 pm, Michael Kay
mike@xxxxxxxxxxxx<mailto:mike@xxxxxxxxxxxx>
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:xsl-list-service@xxxxxxxxxxxx
rytech.com>> wrote:

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@xxxxxxxxxxx<mailto:damian@xxxxxxxxxxx>
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:xsl-list-service@xxxxxxxxxxxx
rytech.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 wouldnbt lose them. I also donbt 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<http://xmplifyapp.com/>
t: @xmplify



On 24 Jul 2020, at 12:48 pm, Debbie Lapeyre
dalapeyre@xxxxxxxxxxxxxxxx<mailto:dalapeyre@xxxxxxxxxxxxxxxx>
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:xsl-list-service@xxxxxxxxxxxx
rytech.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@xxxxxxxxxxxx<mailto:mike@xxxxxxxxxxxx>
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:xsl-list-service@xxxxxxxxxxxx
rytech.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@xxxxxxxxx<mailto:terminolator@xxxxxxxxx>
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:xsl-list-service@xxxxxxxxxxxx
rytech.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@xxxxxxxxx<mailto: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<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> (by
email<>)

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.