xml-dev - RE: URI concerns continue

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

-----Original Message-----
From: Michael Mealling [mailto:michael@bailey.dscga.com]

>There are two other URI schems: content-id and message-id. They look
>like this:
>cid:foo4*foo1@bar.net
>mid:960830.1639@XIson.com/partA.960830.1639@XIson.com

>they refer to parts of messages (very useful in MIME). They never
>define how you would resolve one of those in a network. It assumes
>you already have them and you just want to say something to the
>effect of "give me that one over there, not this one right here".

Ok.  The name system defines a unique name and a 
relative location?  Is that right?

>Thus, they have no concept of resolution beyond just looking
>in some local store or database and looking something up by that
>name. (NOTE, depending on how they're assigned (timestamps and all)
>they are not considered persistent).

Ok.  Persistence is an additional characteristic of identity 
similar to the dead man's age problem. (He is dead.  Is he 
he still aging?)  So far, this is an SGML system identifier.  
It carries the semantic that it must be resolvable by the 
local system.  If the local store is a catalog, this is 
nothing moreorless than what SGML provided with the catalog 
systems.

> the series of characters in front of the first colon in
> a URI _do not_ identify a protocol. They identify a naming scheme.
> <snip> The fact that
> the 'http' and 'ftp' URI schemes has a name that corresponds with 
> a protocol is co-incidental only and has no meaning.

The coincidence is part of the problem.  We end up with a 
superstion about resolution.  This lack of clarity seems 
to be at the root of the definitional issues.

>In my mind the SYSTEM identifier was nothing more than a degenerate
>Catalog that got shoved around with the Doctype line. So its still
>a lookup in some database. Its just a simple database of one element.

I'm not sure why that is degenerate.  It seems to be the same 
issue as discussed above.  Now, if we don't have a <!DOCTYPE 
and a system identifier, we have a problem.  On the other 
hand, we can have both a public id with a system identifier, 
and we have a strong assertion about the identity and the location 
of a resource corresponding to that identity.  Note, this is 
not a provable assertion, just a contract.

> Its just that, for some 
> identifiers, the lookup function involves destructing bits of 
> the identifier in order to find what part of the database the 
> record is currently in. 

Ok, we have a system semantic here.  That is fine as long as 
that is understood and a sharable semantic.

> Specifically, in the area of URN resolution
> we specifically say that the first step is to ask some local
> context about it first.

Yes.  So far I understand but am not sure how this was 
better than FPIs plus system IDs.  Had we removed the 
coincidental protocol/namesystem morphs, we would have 
exactly the same systems, yes?

> Like I said, any identifier is always 'resolvable' by simply
> looking in a database. 

Hmm no, because that database may not be available.  Tedious, 
but true.  "May be resolvable" is true.

>The fact that a namespace identifier
>happens to be a URI and thus the database lookup function
>follows some specific rules based on known syntactic elements
>of that identifier is really irrelevant to still being
>able to use that identifier to name the namespace.

Hmm, no.  What is at issue is the guarantor of the 
behavior or in reality, the guarantor of the probability 
of a correct resolution.  Again, tedious but true.  
 
<snip why="same ground" />

> Of those URI schemes, the following do not have any
> associated protocol: news, file, cid, mid, service, data, tel, fax, urn.

I see the point.  The only guarantee is the syntax, but 
I am unsure what the guaranteed semantic is?

 
>> Btw, since you insisted on resorting 
>> to the tired "counter-productive, SGML-ish, bifurcation of
>> public vs system identifiers" insult disguised 
>> as argument, let me go ahead and call you the white spy so 
>> you can assume I am the black spy and 
>> we can get on with the dominance game.  

> ;-) Sorry 'bout that...

That's ok.  I don't want to lose my status as an 
SGML curmudgeon.

> I wonder how long it'll be before we degenerate into a Hytime vs Web
> argument....

Not today. By the time one gets through the whole family of XML 
standards, most of Hytime is there anyway.  We only get into 
that argument when someone says Hytime Bad: Web Good.  Then 
we have to do the Spy vs Spy panels in a new issue of MAD. 
"What Me Worry?  Extend and embrace."

Thanks very much for the examples, Michael.  Very helpful.

len (alfred e. neumann was my friend)