why do namespaces have such a bad rep [3]

[james anderson]

hello again.

Steven R. Newcomb wrote:

> Let me put it even more starkly.  It makes no sense, in a small living
> room (the short supply of mindshare and attention), to replace a
> comfortable sofa (enabling architectures) with a rude wooden bench
> (namespaces).  It doesn't matter how many times you say that the
> wooden bench is perfectly good for the purpose for which it was
> designed, and it doesn't matter how many times you point to the
> bench's original specifications when people complain that, in
> practice, the bench is sometimes very uncomfortable and a sofa would
> be much more useful in a wider range of everyday living situations.
>

perhaps you have misundertood me.
my living room is big enough for me to have a couch and a coffee table. i could sit
on the coffee table. i don't. i could balance my coffee cup on my lap when i sit on
the couch. i don't do that either.
and no, i don't have a couch with drive-in movie arm rests. they would make it hard
to do some of the things i bought the couch for.
and when someone shows up with a birthday cake, i'm happy not to have to send them
out to the kitchen to cut it up and put it in coffee cups, 'cause that's all we would
have been able to balance on the armrests.
and when i didn't yet have the couch, but i'd picked up the coffee table real cheap
at a yard sale, it was still nice not to have to sit with my cake in my lap when i
was sitting on pillows.
and now that i have the couch, there's no reason to throw the coffetable out. it
turns out that, when company comes they like not having to eat out of their laps just
as much as i do.

i find it easier to make decisions when separable issues are handled separately. so i
have to speak out for namespaces, since, in my experience, they  conserve "mindshare
and attention".

to make my concern concrete, let's take up again the issue behind my question about
ArcCFC. you responded, that,

> entity names in your inheriting architecture are entirely your
> business.  In fact, even when inheriting any number of enabling
> architectures, means are provided to allow you to prevent them from
> affecting any of the inheriting architecture's namespaces in any way.

i'm concerned about the case were i want to get at them, not be isolated from them.
i would expect to have to do something like the following. suppose that i have two
base architectures, each with an element "name". i would like to derive an
architecture to comprise descriptions of both sorts. nothing new.

<!-- base arch 1. -->
<!ELEMENT name ((first, last) | %name-content;) >
<!ATTLIST name
  address-form (PSEUDONYM | LEGAL) "LEGAL">

<!-- base arch 2. -->
<!ELEMENT name %name-content; >
<!ATTLIST name
  address-form (ASSOCIATIVE | LITERAL) "LITERAL">

while the provisions of enabling architectures make it possible to use architectural
form attributes to  disambiguate the "name" element names by creating a 2-d namespace
for element names, and to disambiguate the "address-form" attribute names by using
the remapper attribute to, likewise, create a 2-d namespace for attribute names, and
then to map them onto unique positions within a 1-d namespace, i have not found the
provision to enable declaring distinct values for the entities. how would one
distinguish %name-content from %name-content in a derived architecture in order to
specify the respective entity declarations?

maybe i don't need to. i thought i would.

if the mechanism for entities does exist, then i'll be using three distinct
constructs to accomplish the same thing. (yes, i'm ignoring the translation
facilities of attribute mapping here - as i always seem to say "they're orthogonal")
which does not recommend the approach as a paradigm for the efficient use of
"mindshare and attention", but at least i can be confident that i will be able to do
what i  need to in the existing e-a implementations.

bye for now,



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)