- From: Michael Mealling <michael@bailey.dscga.com>
- Date: Mon, 5 Jun 2000 10:09:39 -0400
- To: "Clark C. Evans" <cce@clarkevans.com>
- Cc: John Cowan <cowan@locke.ccil.org>, Larry Masinter <masinter@attlabs.att.com>, xml-uri@w3.org
On Sun, Jun 04, 2000 at 03:45:15PM -0400, Clark C. Evans wrote: >On Sat, 3 Jun 100, John Cowan wrote: >>Larry Masinter scripsit: >>>>Au contraire. The "data:" scheme is the only one for which it is *known* >>>>that if two URIs are different, the resources are different too. >>> >>>data:,abcd and data:text/plain,abcd are different, but identify the >>>'same' resource. >> >>Oops, you are right. That's a slip-up on my part. > >Yes, but its not fatal killer for the idea. Let's just >introduce a new scheme (similar to data:) that does not >have this problem -- call it "xmlns:". > >1. The "body" of this new namespace can then > be one of two things, (a) an URI reference > or (b) reverse.dns.package Don't use DNS names. They violate the persistence requirement.... >2. Comparision of the URI is defined character-by-character > without absolutization of any contained URI reference. > >3. The "URI reference" possibility for the body is > deprechiated, and absolutization/resolving of any > existing documents with a "URI reference" body is > also deprechiated (to stop the quacking). >4. The URI identifies a namespace, the identification > function is one-to-one and onto (injective and surjective). All URIs have this quality so why not use them? >5. If a xmlns:prefix="attval" is not a valid "xmlns:" URI, > then the attribute value is considered as the "body" of > a valid "xmlns:" URI. > >Thoughts? Overly engineerd to satisfy a perception instead of the actual truth WRT to URIs and their properties... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com
Received on Monday, 5 June 2000 10:21:07 UTC