Re: Name namespace, namespaces and names in general

On Mon, 14 Feb 2000, Jonny Axelsson wrote:

> At 19:31 13.02.00 -0500, Arjun Ray wrote:


> It is wrong if it leads to problems or limitations now or in the
> future.

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

> "Not used as originally intended" is not wrong. 

I couldn't disagree more strongly.  The use is governed by a standard.
Why have standards at all, then?  

> Generally speaking, no worthwhile development or invention has
> been used as originally intended.

This is completely specious.  The "invention" in question - it's
actually a *convention* - exists at all *only* because of a defining
standard that had the good sense to provide for a necessary *and*
useful concept.

> 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 (?))

Only if it's unique.  Otherwise you're talking about a list (of
elements) or a forest (of subtrees).

> 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 (?))

You've changed the premise.  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.)

But, allowing this, I still don't agree.  A 1:1 mapping would
unnecessarily constrain the ability to refer to the external ID from
within a HTML document.  The *natural* circumstance will be a N:1
mapping, so the problem is one of arranging for N IDs in the HTML
document.  If you want to recover a 1:1 mapping, one (somewhat flawed)  
answer could be to embed that mapping in the IDs, e.g. each ID being a
compound of that mapping and a local counter (which can be ignored
when extracting the key.)

> 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.

Without knowing which code you're refering to (ID construction?  Key
extraction?  Markup recognition in context?), I'd say my suggestion
rates to be a one-liner.  (I wouldn't do this, but that's a different
story.)

> 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.

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.  

> 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.

The "two identical IDs" are both *references*.  Just because you want
to *call* them (HTML) IDs doesn't make them so, and in fact, their
postulated duplication automatically disqualifies them, your usage
notwithstanding.

> > thanks to crippleware and apparently everyone's abject
> > dependence, you have nothing else to "use", it seems.  
> 
> In a fundamental way, yes. It is a practical way to be able to do
> "external system -> HTML -> external system" without losing
> information. 

It is not practical.  It is merely a shortsighted concession to the
ephemeral convenience of having a one-liner in one particular use
scenario.  You're basically saying "*I* have no use for unique IDs, so
why not let's *all* of us give them up?"

> >Yes, but misusing IDs won't help any.  

> Nor harm. 

I beg your pardon?  It will compromise every software system written
to a standard that specifically *allows* the uniqueness constraint to
be exploited and optimized for - all in the name of needless fiddling.

> It could help a little bit, as it gives an incentive to attach
> more information to the code,

So add the information!:)  Stick in a dbKey atttribute wherever you
like: after all, you're the only one who has any use for it.

> >> 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.

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

> >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. 

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:))

> You can't connect DOM or CSS to it AFAIK, 

I can imagine the DOM being the basis of an XPointer implementation,
so I don't understand what you mean here.  CSS already has a set of
path-relative primitives to express the same "drill-down" of XPointer,
so if anything it's a matter of unifying the syntaxes perhaps:)  

> For changing documents there is a difference between refering to a
> document by XPointer and by IDREF. 

Not at all.  The #xpointer(id(foo)) construct is *exactly* an 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),

Huh?  Could you cite a reference in either the CSS or XPointer
specs for this remarkable fact?

> but the ID remain "sect3.2", making it possible to refer to the
> same piece of code even when the context is changing

Precisely why CSS and XPointer refer to (and *rely* on the uniqueness
of) IDs.  Neither has any clue about 4.2, AFAICT, nor for that matter
would they have to care. 


Arjun

Received on Monday, 14 February 2000 07:31:42 UTC