Re: Name namespace, namespaces and names in general

At 19:31 13.02.00 -0500, Arjun Ray wrote:
 
>I think you're missing the point.  Your practical reasons (as
>motivation) are not in question, at all.  It's the use of ID to meet
>those requirements.  That's wrong, because ID is not a freebie to be
>redeployed like this, so a genuine solution for your problem isn't in
>this direction.  (I'll devote a separate followup to this.)

It is wrong if it leads to problems or limitations now or in the future.
"Not used as originally intended" is not wrong. Generally speaking, no
worthwhile development or invention has been used as originally intended.
In this case it is not such a subterfuge (IMHO), what I did was to add 2 to 1:

1. An ID is a hook for an element/subtree (all agree (?))
2. If that ID can be simply 1:1 mapped into an IDREF/ID in an external
non-HTML system, you can take advantage of that (you don't agree (?))
3. An ID is not a label (yes, I agree; we have TITLE for that)

On the "simply 1:1 mapped" bit, what I wanted to achieve in the original
example was a straightforward way to connect the HTML ID and the external
ID in, say, at most one line of code. Removing spaces will not do, as there
is no way to put them back in again, replacing_them_with_underscore is OK
(if there were no "natural" underscores), using an external table for
arbitrary mapping is no good either.


>> Though if the process adding IDs is unconnected to the one
>> maintaining the external data store, that table is not so simple
>> to make. Not *having to* use such a table can easily make (X)HTML
>> "live" today.
>
>It could be much simpler than this if people realized how egregiously
>**BROKEN** their wowsers are [...] but perpetuating kludgery isn't bringing
>better days any closer.  (Yeah, let's all wait for the *other guy* to
>show the way, right?)

This suggestion, good or bad, has nothing to do with browsers (awful as
they generally are), has it? Neither is it a kluge (as in "complex
contraption") in my opinion. And finally, this I should stress before it
gets lost in the discussion, it was just an example of how two identical
IDs could appear in the same document, not a plea to conform IDs to some
great database connectivity scheme of mine.


>In this case, that you're "limited" to <table>, <tr>, and <td> is in
>your way - thanks to crippleware and apparently everyone's abject
>dependence, you have nothing else to "use", it seems.  Without extra

In a fundamental way, yes. It is a practical way to be able to do "external
system -> HTML -> external system" without losing information. The HTML
itself is suboptimal as it comes to interoperability, but no worse than an
HTML document with "random" IDs.


>Yes, but misusing IDs won't help any.  
Nor harm. It could help a little bit, as it gives an incentive to attach
more information to the code, but in practice that information might not be
in a form that is transformable into something useful for that general case.

>Most of the time, bad practices are the result of bad expectations.
I call them mental models or concepts, but I fully agree with that. I am
wary of things that may cause those expectations/models or taking advantage
of peripheral or implementation specific properties, but 2. above is neither.

>> The issue is I want mnemnonic IDs. 
>Actually, you want mnemonic *references*.  IDs in XML documents are
>not referential.
No, I want to refer to IDs without having to look them up in the source
code every time.


>Are you also implicitly saying "It's gotta work in Netploder today"?
No, I generally don't worry too much about backward compability in this
context, especially not to broken practices.


>This is a different issue.  URLs are not friendly in that respect -
[...]
>really not worthwhile discussing how to make URLs easier to remember
>or to transcribe.  They are irredeemably geeky.

It is the "human readable" ideal that crops up in almost any web standard.
It is not strictly necessary as most of it is supposed to be processed by
machines anyway, but for every protocol/format I have encountered, that
property has been from somewhat to extremely useful. I do type in a large
number of URLs and prefer short URLs and URLs I can put in my short term
memory. Thus the difference for me is not between straightforward and
complex/geeky, but between complex/geeky and random.

>Have you taken a look at XPointer?
Yes, it is a good thing, and it removes the need for most run of the mill
IDs. You can't connect DOM or CSS to it AFAIK, so ID is still required for
those cases. And I would still use IDs for important "shortcuts" (shorter
URLs, not dependent on XPointer support.

For changing documents there is a difference between refering to a document
by XPointer and by IDREF. If Section 3.2 has ID="sect3.2", a new Section 2
is added, the old Section 3.2 is now 4.2 (for CSS and XPointer), but the ID
remain "sect3.2", making it possible to refer to the same piece of code
even when the context is changing (if HTML/XML documents were versioned,
the best practice would be to refer to the version at the time, with a
server option to tell about or show the newer version).

Received on Monday, 14 February 2000 03:13:48 UTC