[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: "Eliot Kimber ekimber@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 24 Jul 2020 16:48:02 -0000
Re:  xmlns in the root element prevents transformation
Norm said:

    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.

If my memory is correct, we (the XML Working Group) wanted to use PIs for
namespace declarations and they would have preceded the elements to which they
apply (or the root element, I guess--I don't remember the details of that
aspect of the proposal).

The design decision was overridden by Tim Berners-Lee and we were not happy
about it but there wasn't much we could do. It was that overriding of a
technical decision that led me to leave the W3C (I ultimately returned to X3C
work in order to contribute to XSL-FO and XSLT, having gotten over myself).

At the time, I felt that using attributes on the elements to which they apply
to do this kind of name declaration violated every tenant of markup design and
declaration practice I had learned from SGML. SGML was all about precision and
completeness of declaration. Bless its heart.

I also objected to the fact that the namespace spec seemed to imply (or did
not clearly refute the assumption) that there was, in general, some knowable
relationship between namespace names and vocabularies when there is not--the
only reliable association between namespace names and vocabularies is when the
definition of the vocabulary makes the association and also constrains the
vocabulary it defines. That is, if I see "myprefix:foo" and I know that
"myprefix" maps to "urn:ns:mynamespace" I know that "myprefix:foo" is a
different name than "yourprefix:foo" (assuming yourprefix is bound to a
different namespace name) but I can't infer anything about "foo". In
particular, I have no idea if "foo" is actually an element in the
(presumptive) vocabulary named by "urn:ns:mynamespace".

That is, namespaces are only, as defined, good for disambiguating names. They
are not good for validating against grammars. XSD made the mistake of equating
namespace names with sets of element types, which leads to all sorts of
problems (and don't get me started on the XSD default namespace feature...).

One could imagine some kind of DNS-like system for mapping from namespace
names to formal grammar definitions, but then who would use it? In practice
you either don't care, because your namespace is more or less private or it's
defined in some recognized standard and the namespace-to-name-set rules are
(or should be) clear. And what would your grammar definition be? It would be a
mess and nobody would implement it or use it.

But I don't think the vast majority of namespace users understand this
somewhat subtle aspect of namespaces.

Cheers,

E.

--
Eliot Kimber
http://contrext.com


o;?On 7/24/20, 5:30 AM, "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.