why do namespaces have such a bad rep [2]

[james anderson]

hello again;

first, an aside for those who may wonder why i pursue this. my concern is that i
do not wish to have to implement support for enabling architectures just in
order to contend with name collisions. on principle it would be wrong.
practically it would be a waste of time.

perhaps i have had the rare fortune of having been spared some experience which
would have led me to believe that a particular syntactic notation for a name
(the ':' between two parts) necessarily imputes any o-o behaviour to an entity
thereby denoted. still, i would ask that, in this forum, were the distinction
has been made clear, we should strive for a state where it is well understood.
where possible sources of confusion are explicated and resolved, and where they
are not taken as a justification discredit the notation for not accomplishing
something to which it makes no claim...

i propose, as a general principle, that the two words "inheritance" and
"namespace" not be used in the same sentence, unless the sense is that of a
conjunction between two unrelated things.

> James Anderson <James.Anderson at mecom.mixx.de> writes:
>
> > why? what does colon syntax have to do with class inheritance?
>
> Expectations created by vague recollections of OO syntaxes that use
> colons to delimit class names.  No more, no less.  I'm not claiming
> that it's a logical or appropriate presumption.  I'm just observing a
> fact.  Real people -- people I respect -- are misunderstanding what's
> happening here, and in a big way.  Moreover, it's a difficult
> misunderstanding to clear up, and clearing it up inevitably casts
> Fear, Uncertainty, and Doubt on the whole XML thing, which is
> something I really don't want to do.
>
> > 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.
>
> Yes.  I said that.

it's the "inherited" part that's the problem. the dtd is not thereby
"inherited".

>
>
> > > 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.
>
> That's right.  However, the fact is, people need inheritance.  The
> closest thing XML provides today is namespaces.

the issues are orthogonal. that is, it can't be close: it's off in another
dimension. if the discussion is about inheritance per se, one need not introduce
namespaces. take the reference literature on CLOS.steele manages dozens of pages
respectively on the package system and the object system - without ever needing
to mention one in the context of the other. keene's "programmer's guide to clos"
mentions packages only to clarify that they have nothing specifically to do with
objects. when the topic is inheritance, don't even bring namespaces up...

there is, in general, much to be said for implementing unrelated things with
separable mechanisms.

> The unsophisticated
> are confusing namespaces with inheritance.  This is a Bad Thing for
> XML and W3C, because when their eyes are opened, these people will

the sooner the better

> feel betrayed and their honeymoon with XML will suddenly be over.
> "You mean there's no XML way for me to say that I want to treat this
> element as if it were this other element type in this other document
> type?  What kind of pseudo-object-oriented horseshit is this XML
> thing, anyway?"  And when you consider that namespaces are a
> suboptimal approach to the problem RDF is designed to address -- the

i don't know the "RDF history". i'm just reading the proposal and considering
the implications for implementation and application. i use namespaces. i have
implemented namespaces. i could have implemented attribute mapping. it would not
have resolved all of the things i would expect to need wrt element inheritance.
further, while attribute inheritance is supported, and the subtyping wrt
validation of references is resolved, the mechanisms for structural inheritance
avoid most of the difficult issues by specifying that the base architectures
have nothing to do with each other. in the situations i'm trying to model that
would lead either to repeating content definitions (which is
counter-inheritance) or introducing artifactual structure.
it would been much more complex and, as i understand (ISO/IEC 10744:1997 Annex
A.3), it would not have accomplished everything i would have implemented it for.

(WD-xml-names-19980327 doesn't either, but that's an unrelated issue - and at
least i can rightly argue that, wrt namespaces, it should...)


> ...
> > it also has equivalent mechanisms to manage the same problem within a
> > one-dimensional namespace.
> > (i.e. the problem doesn't go away)
>
> Huh?  What problem doesn't go away?

name collisions. (please see below)

> > 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 attribute...
>
> Do you think that providing a mechanism for renaming things is all
> that inheritable architectures have to offer?

neither do i believe that, nor did i say so. the discussion was directed solely
at the facility for renaming and made no reference to the remaining scope of
ISO/IEC 10744:1997.

> If so, you'd better
> study this topic some more.

you're right there. one thing i still need to understand is how i would, for
example, define things like the ArcCFC entities for multiple inherited
architectures (ISO/IEC 10744 p230), or handle possible name ambiguity between
multiple architecures wrt entities used to specify section inclusion (ISO/IEC
10744 p223)
(yes, i lack experience there. i woud presume one helps oneself to dotted names,
but that's just conjecture)


> That's just a housekeeping feature.
>
> > 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?
>
> Because:
>
> * people need inheritance more urgently than they need namespaces;

that's an orthogonal issue. (see above)

> * if they had inheritance they wouldn't need namespaces

they are orthogonal issues. (see above) that (ISO/IEC 10744:1997 Annex A.3)
contains specialized provisions to address a subset of naming issues should not
lead one to claim that another aspect of the standard - inheritance, in itself,
provides a solution for name ambiguity.

> (even your
>   "greater compactness" argument will not stand up to scrutiny because
>   the ISO inherited architectures syntax can make much more compact
>   documents than the proposed namespace syntax ever could);
>
> * nothing else in XML, today, even looks like inheritance; and

that (Prefix ':')? LocalPart "even looks like inheritance" is a misconception.

> * there is nothing in XML, today, that does inheritance.

that's an orthogonal issue.

> However, if the W3C would simply acknowledge that an XML-ready
> mechanism and syntax for true architectural inheritance is already
> available in an existing ISO standard, this whole problem would
> vanish,

the problem does not "vanish", (some of) it (please see above) has just been
worked out another way.

...


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)