RE: URI concerns continue
-----Original Message----- From: Michael Mealling [mailto:michael@b...] >There are two other URI schems: content-id and message-id. They look >like this: >cid:foo4*foo1@b... >mid:960830.1639@X.../partA.960830.1639@X... >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)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format