[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: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 24 Jul 2020 12:31:30 -0000
Re:  xmlns in the root element prevents transformation
I think the core of the problem is that in languages like Java, "String" is
clearly just an abbreviation for "java.lang.String", and anywhere you don't
want to use the abbreviation, you can write "java.lang.String" intead, and
it's clear to everyone what's going on. The short name gets expanded to the
long name as soon as its parsed, and after that you never need to think about
it. The problem with XML namespaces is that you can't use the expanded name in
place of the local name, which means you can't expand names as soon as they
are encountered in the XML or XPath parser and then throw the context away.
The namespace context, as a result, pervades the whole system.

Michael Kay
Saxonica

> On 24 Jul 2020, at 11:30, Norman Tovey-Walsh ndw@xxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> With a little trepidation, Ibm going to wade into this threadb&
>
> The first observation Ibll make is that there are other languages that
> allow local names to be in a default namespace. They donbt call them
> namespaces and they donbt work *exactly* the same way, but you donbt
> have to fully qualify every class and method name in, for example, Java
> and Python, because you can import a package and then use its names in
> an unqualified fashion.
>
>  Widget x = new Widget()
>
> is as meaningless cut-and-pasted out of my Java program and pasted into
> yours as
>
>  <widget>X</widget>
>
> I donbt know if itbs the fact that lots of successful XML developers
> donbt think of themselves as programmers that exacerbates the problem.
>
> Itbs unclear if the overlapping-global-namespaces problem that would
> exist if there were no namespaces (and the kludgy, ad hoc solutions that
> would have been developed to deal with them) would be better than
> namespaces or not.
>
> Damian Morris damian@xxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
writes:
>> 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 :)
>
> Nope. I totally disagree. I point as evidence to XQuery which totally
> borked things by allowing the in-scope default namespace to apply to
> unqualified names in XPath expressions. Consider:
>
>  let $x := doc("mydoc.xml")/*
>  return
>    <div xmlns="http://www.w3.org/1999/xhtml"
>         class="$x/classprop">
>      { $x/path/to/thing/string() }
>    </div>
>
> That completely doesnbt work (unless mydoc happens to be in the XHTML
> namespace, of course).
>
> I canbt count, and would prefer not to consider, the number of places in
> my XQuery code where Ibve been forced into the most awkward contortions
> in order to get expressions evaluated *outside* the context where I need
> them just because the [expletive deleted] default namespace declaration
> [expletive deleted] my XPath expression.
>
> The XSLT rule that says an unqualified name in an XPath expression is in
> no namespace regardless of the in-scope namespaces is exactly correct.
> It doesnbt bother me that you can override that with a declaration, I
> just wouldnbt ever do that.
>
>> On 24 Jul 2020, at 4:54 pm, Michael Kay
mike@xxxxxxxxxxxx<mailto:mike@xxxxxxxxxxxx> 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.
>
> Itbs a shame that XML was forced to adopt a weird, pseudo-attribute
> based namespaces design that introduces all sorts of scoping complexity.
> It was done, as I recall, because the folks doing RDF/XML had already
> made some really weird decisions about the semantics of RDF/XML and XML
> namespaces were damned well going to fall in line. Global declarations
> at the top of the file would have addressed the overwhelming majority of
> cases.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Tovey-Walsh <ndw@xxxxxxxxxx>
> https://nwalsh.com/
>
>> Nothing travels faster than the speed of light with the possible
>> exception of bad news, which obeys its own special laws.--Douglas Adams

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.