Lists Home |
Date Index |
- From: james anderson <James.Anderson@mecom.mixx.de>
- To: "firstname.lastname@example.org" <email@example.com>
- Date: Wed, 01 Apr 1998 06:02:40 +0200
why do namespaces have such a bad reputation? in particular, why are they
discredited for having been conflated with something which they are not, and
which they do not claim to be?
Steven R. Newcomb wrote:
> David Megginson (firstname.lastname@example.org) writes:
> > Personally, I'd recommend architectural forms over namespaces if
> > you're concerned with DTDs, since architectural forms have several
> > major advantages:
> David is right.
> But I would go farther: XML Namespaces are a snare and a delusion.
> With their use of colon syntax, they lull one into thinking that that
> are about class inheritance.
why? what does colon syntax have to do with class inheritance?
> They are not.
> Instead, what the
> namespace thing does is to collapse all the structure of the classes
> of the inherited-from DTD into a salad of element types which is very
> correctly termed a namespace rather than an architecture. All that
the namespace 'thing' maps the names from the "inherited from (sic) DTD" into a
unique region of a two dimensional namespace. it says nothing at the structure.
> RDF was looking for was a way to guarantee global uniqueness of
> element type names, and if we ever try to get anything more than that
> from namespaces, we are on very thin ice indeed.
agreed, but it doesn't claim to.
> If the inherited-from DTD is already a tag salad, in which all the
> element types are a big OR group in the content model of the document
> element, namespaces can work quite well. If, however, an element type
> has different meanings depending on its context (and most
> architectures necessarily have this characteristic), then collapsing
> such an architecture into a namespace can actively interfere with
> information interchange.
the wd doesn't propose to collapse the architecture, it proposes to map the
> I think RDF would benefit substantially, in terms of its
> understandability, its implementability, and its flexibility, if it
> were described in terms of inherited architectures. In fact, I think
> it cries out for an architectural perspective, in which the
> knowability and significance of element context is preserved.
which all may be true, but doesn't say anything about what namespaces do.
> Anyway, all is not lost. This namespace thing is a mistake that will
> necessarily be corrected, simply in order to support the needs of
> civilization in an XML-dominated world. The way toward a solution is
> already paved by an ISO standard (ISO/IEC 10744:1997 Annex A.3) that
> is being adjusted to accommodate the syntactic limitations of XML
> (i.e., its lack of #NOTATION attributes). It is implemented in the SP
> parser and in other software systems, and it is already being used in
> many industrial contexts. It's the right sort of answer, it's not
> going away, and its usage is accelerating rapidly; there was a
> manyfold increase in the number of papers reporting its use at
> SGML/XML 97.
it also has equivalent mechanisms to manage the same problem within a
(i.e. the problem doesn't go away)
some may find the ability to rename an advantage, as it allows one to alter the
intended semantics. i wonder whether it as often leads to confusion. where the
issue is really name-uniqueness, namespaces are a much more compact expression.
there's no reason they couldn't be integrated into sgml architectures - but for
the deconstructivist aims, they'd accomplish the same thing as the renaming
why wouldn't people just take them for what they are - orthogonal to the issue
of structure, and use them for what they can do?
bye for now,
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)