[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 14:10:22 -0000
Re:  xmlns in the root element prevents transformation
I will observe that the DITA standard does not (and cannot really) use
namespaces except for inclusion of foreign vocabularies, where namespaces are
required. The DITA standard does use a namespace for itself in one very
important way: it defines a mandatory attribute that is in a DITA-defined
namespace that serves to unambiguously identify the element it's on (which
must be the root element of a conforming DITA document) as being a DITA
document. This is important because the potential set of names for conforming
(and immediately-processible) DITA documents is unbounded. So we needed some
signal to say "This document asserts that it is a DITA document" and an
attribute in a namespace defined by the DITA standard does that perfectly
well. Otherwise, all DITA elements and attributes are in no namespace.

The DITA standard cannot use namespaces because it uses a private syntax to
correlate element names to a simple declaration of element type derivation
hierarchy (the DITA @class attribute, i.e., "- topic/p gaonb-p-d/figureLegend
"). In the context of the @class syntax, which was designed specifically to be
easy to select with CSS string-token selectors (*[class ~= 'topic/p']), you
would have to either fix all your namespace prefixes, which is sort of missing
the point of namespaces, or require processors that operate on @class values
to do namespace lookup as part of that, which would then break the CSS
ease-of-selection use case. Or the values of @class attributes would be very
long indeed, with each namespace name included in the value, which is not
ideal either.

But as DITA is expressly designed to allow controlled definition of new
vocabulary that can be more-or-less blindly integrated with other DITA
vocabulary modules it faces the same potential name collision issue that XML
namespaces were originally designed to address.

DITA's solution is simply to use the functional equivalent of namespace
prefixes in the names of elements intended to be mixed in with any other
elements, i.e. "lt_" for all the elements in the Learning and Training
question-and-answer vocabulary. It ends up being just as good as conventional
namespace prefixes but without adding any additional processing or declaration
overhead.

We've tried several times to work out a way to do real namespaces in the
context of the @class value syntax and have not yet arrived at one, but also
the efforts keep getting pushed to the side because the need for it seems more
theoretical than practical.

On the other hand, without namespaces, it would be practically impossible to
include foreign vocabularies like SVG and MathML, where there are name
collisions that would be unreconcilable if all matching was only on local
names, especially when using DTDs (with RNG I think you can make it work but
we can't limit the DITA community to RNG).

Cheers,

E.

----
Eliot Kimber
http://contrext.com


o;?On 7/24/20, 5:34 AM, "Pieter Masereeuw pieter@xxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:






        My experience is that namespaces are useful but far too often
          used without a real need. Some people seem to like complexity. I
          don't.

        Unless you want to live by a prefix only, you only need
          namespaces when you mix several XML languages, such as in the case
          of XSLT and XSL-FO (where you can mix in foreign content, such as
          SVG).
        In cases where I design my own simple XML, I avoid using them, to
          keep things simple.
        By the way: living by prefix only may be theoretically unsound,
          but, as an example, if your root element is xsl:stylesheet, and if
          it is being processed by an XSLT processor, then for all practical
          purposes it's obvious what the prefix xsl means.
        Pieter

        On 7/24/20 12:07 PM, Mukul Gandhi
          gandhi.mukul@xxxxxxxxx wrote:





              On Fri, Jul 24, 2020 at 8:18 AM Debbie Lapeyre
                dalapeyre@xxxxxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
                wrote:




    Namespaces are a real
                  problem.




                I personally, find XML namespaces functionality useful.
                  At the moment, the online downside I see for XML
                  namespaces is, that sometimes they appear verbose.


                We can also see, functional analogues of XML namespaces
                  in the other languages (like packages in java).





              --






                          Regards,
                            Mukul Gandhi











                XSL-List info and archive
<http://www.mulberrytech.com/xsl/xsl-list>

                EasyUnsubscribe
<http://lists.mulberrytech.com/unsub/xsl-list/3208261>
                (by email <>)








    XSL-List info and archive
<http://www.mulberrytech.com/xsl/xsl-list>EasyUnsubscribe
<http://lists.mulberrytech.com/unsub/xsl-list/1278982>
    (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.