Re: Name namespace, namespaces and names in general

At 07:53 14.02.00 -0500, Arjun Ray wrote:

>Once you have "non-unique IDs", how do you propose to get unique IDs
>back?  Add another kludge to tell the, um, difference?

*That* would be a serious change of the standards. 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). Since I aired several
related but independent issues at the same times, I'm sorry if this caused
confusion. What *I* thought I was arguing for the last few messages was
that I could use HTML/XML IDs that have meaning in some external context.
Even if that is not what was originally intended by IDs, it still won't hurt.

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. So on to the other
controversy.



>You've changed the premise.  
Yes I did. While using some external key value directly as HTML IDs is
preferable, a transform function is possible too if it is simple and
reversible, and certainly better than a lookup table, which in turn is
better than random IDs from the view of the external system.

>You were talking about non-unique IDs,
>specifically catering to a N:1 mapping (e.g. the dbKey being the same
>for an ID, but the ID being repeated in the document when more than
>one reference to a specific dbKey was needed or unpreventable.)

[mode change: exploratory] That sums it up quite well. 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. The
table wouldn't have been necessary without the constraint.



>Now you're saying that not only does the external ID have a wider
>domain than SGML/XML IDs, but also that a 1:1 mapping must still
>obtain under these circumstances.  That's impossible.  

[mode change: available ID value characters] 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.



>> No, I want to refer to IDs without having to look them up in the
>> source code every time.

>I'm sorry, but I have no idea what you mean here.  Which IDs?  In what
>source code?  When?

Consider a glossary.html, with items like these:
<def id="KtU17-816v">confusing</def>
<def id="mnemonic">mnemonic</def>

It is easy to refer to <a href="glossary.html#mnemonic"> without actually
looking at the code. If the naming scheme uses an alien scheme, such as the
"confusing" example, you have to study the code.

>I don't think there's a necessary implication one way or another.
>XPointer is a way to improve on the situation when there *isn't* an ID
>that already references the desired document fragment directly (i.e.
>it's a generalization of the fragment identifier concept, not a
>criterion to decide when to use or not use IDs in a document:))

I used to put in as many IDs and A NAMEs as reasonably possible (still do).
Not because they necessarily "deserve" an ID, but because I know that is
the only way for me or anyone else to refer directly to them. If XPointer
was widely available, I wouldn't do that.



>> 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),
>
>Huh?  Could you cite a reference in either the CSS or XPointer
>specs for this remarkable fact?

To expand the example, if <chapter> correspond to chapter numbers, and
<sect> to section numbers, and you use XPointer to point to the second
<sect> in the third <chapter>, and an earlier <chapter> is added, "3.2" is
not pointing to the same text anymore, that text is now the second <sect>
in the *fourth* <chapter>, but it still got ID="sect3.2". So since CSS
numbering schemes and XPointer points to position, they are less reliable
than IDs.

Received on Monday, 14 February 2000 13:24:30 UTC