Re: Name namespace, namespaces and names in general

On Sun, 13 Feb 2000, Jonny Axelsson wrote:

> At 19:11 09.02.00 -0500, Arjun Ray wrote:

> [[First, thanks for the URLs you gave]]

The best staring point for HyTime is www.hytime.org, but for some
reason DNS hasn't been resolving that for about 2 weeks.  It's run by
the people at TechnoTeacher (techno.com), so for now this will work

   http://209.41.82.60/

which leads to this (via the 'Papers' link on the main page)

   http://209.41.82.60/papers/htguide.html
 
> > It's important to distinguish between 'ID' as a name and ID as a
> > declared value.  The 'unique namespace', in this case, is defined
> > by [the latter, and is specific to each document by definition]

> Yes, I consciously "overloaded" ID by giving the ID a meaning
> (reference to some external scheme), but I did it for good
> practical reasons.

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

> Not doing so would add a "conversion layer" to (X)HTML if some
> other process or person want to access.

That's true anyway.  The access *method* itself is a conversion layer
regardless.  All that matters is that the method implement precise and
known semantics.  (That, btw, is the heart of the location methods
that HyTime enumerates in such exhaustive detail: one doesn't have to
do it the HyTime way, but it's important to realize that any shortcut
is *still* doing what HyTime is describing, so the deflection from the
general case has to be clear about the relevant tradeoffs.)

> It doesn't have to be much, a two column table where one column is
> the (X)HTML ID, the other the "real" reference. 

The general (and flexible) case of such of a map is a bit more complex
than that, actually enough that such a two column table is a waste.

> 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, hysterical hosannas by the chattering
classes notwithstanding.  Such sacred cowsers having become a state of
mind, the problem is made one of how to shoehorn the real expressive
needs of one's information into what hopelessly little everyone's
favorite "advanced technology" tag-slurper can knucklewalk with.  It
doesn't have to be that way, but perpetuating kludgery isn't bringing
better days any closer.  (Yeah, let's all wait for the *other guy* to
show the way, right?)

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
information - markup!? - of *some* kind, you can't even begin to
express the relevant fact that the contents of the <table> have a
definite source and/or semantic connection.

But, what's more important, your information or that <table> markup?

Assuming it's the former, the *solution* has to be one where the
<table> markup is transient or even inferable from the *real* markup.

> That "conversion layer" is not a bad thing. The /semantic web/
> however implemented would add such a layer, making it possible for
> *any* system with proper access to link up the page with that data
> store or other stores.

Yes, but misusing IDs won't help any.  

> Shortcuts, such as the direct HTML<->database linking above, may
> make the road there easier, and it will not conceptual traps like
> "P is like BR, only with a little more vertical space" (that is, I
> don't think overloading IDs is the first step towards any future
> bad practices).

Most of the time, bad practices are the result of bad expectations.

> The issue is I want mnemnonic IDs. 

Actually, you want mnemonic *references*.  IDs in XML documents are
not referential.

> Just as I prefer simple, comprehensible URIs, I prefer
> comprehensible #fraction identifiers. I want simple rules to
> generate and refer to a specific part of a page.

Well, that's what you're saying, but is that what you mean?  The rules
you can have, any time.  But are you also asking that these fragment
identifiers have to be of the sort you're *accustomed* to?  Are you
also implicitly saying "It's gotta work in Netploder today"?

> Generally you try to avoid it, but sometimes you need to refer to a
> fragment in print, like <http://philantroph.net/widows/#application form>

This is a different issue.  URLs are not friendly in that respect -
things with intricate internal syntax rarely are.  Actually, I think
that URLs in print should be avoided religiously.  They were really
not meant to be hand-transcribable on a casual basis (IOW, Joe Surfer
looks at something in print and types it into an input field.)  The
conflict betweeen usability and functionality here has already been
decided - if anything URL syntax will become more elaborate! - so it's
really not worthwhile discussing how to make URLs easier to remember
or to transcribe.  They are irredeemably geeky.

> As for the "Big Question" in my original message, now rephrased
> "Would it be (dis)advantagous to have non-unique IDs in the same
> HTML/XML document (URI)?", I am still curious to the answer. 

> It really comes down to the universal "namespace", which today is
> URI/BLOB, eg. the XML page is the atom. An alternative model would
> be URI/tree.

Have you taken a look at XPointer?

  http://www.w3.org/TR/xptr


Arjun

Received on Sunday, 13 February 2000 19:10:32 UTC