Global declarations at the top of the file would have addressed the
overwhelming majority of cases.
Perhaps it is still not too-late to have a new version of XML/XMLNamespaces
that introduces this? Compatibility can be fully achieved by sensible
defaults.
On Fri, Jul 24, 2020 at 3:30 AM Norman Tovey-Walsh ndw(_at_)nwalsh(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
With a little trepidation, I’m going to wade into this thread…
The first observation I’ll make is that there are other languages that
allow local names to be in a default namespace. They don’t call them
namespaces and they don’t work *exactly* the same way, but you don’t
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 don’t know if it’s the fact that lots of successful XML developers
don’t think of themselves as programmers that exacerbates the problem.
It’s 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(_at_)moso(_dot_)com(_dot_)au
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
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 doesn’t work (unless mydoc happens to be in the XHTML
namespace, of course).
I can’t count, and would prefer not to consider, the number of places in
my XQuery code where I’ve 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 doesn’t bother me that you can override that with a declaration, I
just wouldn’t ever do that.
On 24 Jul 2020, at 4:54 pm, Michael Kay mike(_at_)saxonica(_dot_)com<mailto:
mike(_at_)saxonica(_dot_)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.
It’s 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(_at_)nwalsh(_dot_)com>
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
--~----------------------------------------------------------------
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
--~--