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
On 7/24/20, 5:34 AM, "Pieter Masereeuw pieter(_at_)masereeuw(_dot_)nl"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_dot_)mukul(_at_)gmail(_dot_)com wrote:
On Fri, Jul 24, 2020 at 8:18 AM Debbie Lapeyre
dalapeyre(_at_)mulberrytech(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
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 <>)
--~----------------------------------------------------------------
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
--~--