(unknown charset) Re: Name namespace, namespaces and names in general

On Mon, 14 Feb 2000, Jonny Axelsson wrote:
> At 07:53 14.02.00 -0500, Arjun Ray wrote:

> I'd like to *explore the consequences* of such a change (good and
> bad), but I didn't intend to *use* non-unique IDs before that
> would be a standard (or if I did, it would be for my private
> purposes, and not in an open context).

Sure.  The issue hinges on what ID is for.  If the general need for
unique targets within a document can't be denied - i.e. the *concept*
is useful and relevant - then regardless of any other purposes we
might want to have served, *some* form of uniqueness-guaranteeing
namespace has to be available anyway.  ID is there for that, so it
makes little if any sense to compromise that function.  Right now, I
can't imagine a principle being more clear cut.

(What you do privately, of course, is your own business:))

> If I had declared that I could use non-unique IDs and blame
> everyone else when my pages broke, I would have disagreed with me
> too. 

:-)

> What I meant here was that the ID value mapping should be
> reversible (and 1:1), that is if the external key is "word", and
> for some reason I had to reverse that to use it in the HTML
> document as "drow", I could handle that by reversing it once more.
> If due to uniqueness constraint, I would have to rename a second
> "drow" as "drow2", the simple ID value mapping would no longer do,
> as "word" does not know it is related to "2word". We used "1:1"
> (word <-> drow) and "N:1" (many "word" IDs in HTML document, one
> unique "word" key in external store) in different context. Having
> a N:1 lookup table is a solution, maybe the only one, with the
> current uniqueness constraints. 

I also suggested an algorithmic solution if you insisted on a
computable mapping: instead of "drow2", use "drow.2" and ignore
everything from the (rightmost) dot beyond when figuring out what to
"unreverse".  This gives you the recoverability (at the cost of a
relatively simple string operation in any reasonable programming
language) and maintains the uniqueness constraint too.  Win/win:)

> The table wouldn't have been necessary without the constraint.

I'd have to say that adding an attribute in the document rates to be
far easier to manage in the longer haul than some free-floating table
like this.

> This is not what I originally intended to say, but that leads me
> to the list of acceptable characters. Restrictive rules here may
> make naming and name generating schemes harder. Not having
> characters like space, /()!+*;@$£ can make perfectly good (IMHO)
> naming schemes impossible.

Well, here we're talking about something that's good and works for
everybody.  The fact of the matter is that, beyond a fixed minimum set
of name characters ([A-Za-z0-9]) and some prudent restrictions to
prevent clashes with characters used for markup, the effective set of
name characters is actually *open* to system-specific definition.
(Well, in SGML at any rate.)  That is, the set of name characters
isn't graven in stone.  Now, you could argue against the *particular*
set decided upon in the HTML (or even XML) standards, but unless one
is a Lisp-head, the "unwritten convention" of leaving most punctuation
characters out of the name character set seems to be well accepted, if
not optimized for in many systems.  (Of course, this is an unguarded
generalization, but the point is that *any* decision will impose
*some* costs, so the questions are: have all the tradeoffs been looked
at fairly, and could you expect anything more than that?)


Arjun

Received on Monday, 14 February 2000 15:37:40 UTC