Re: URL better than FPI

> Not quite.  You can't just "connect to a machine".  A TCP connection
> involves a host *and* port combination - and a *defaulted* port is
> associated with a protocol (the 'http:' is what allows you to omit the
> ':80' after 'www.w3.org'.)

True, I realized that, but omitted it for clarity.  Consider connecting
to a server instead of a machine. (perform suitable replacements in my
argument) and consider www.w3.org:80 as the server identifier.
 
> We don't know that from '.dtd' (although a Certain Big Company would
> love it if you fell into the habit of making such assumptions;))  
> And, btw, the public text class 'DTD' in (2) curiously enough means
> 'document type declaration subset' (ISO-8879/10.2.2.1) - note that
> fourth word!

I don't mean that every file ending in .dtd is a DTD, but in this case it
is unofficially indicating it is a DTD.  I admit that in the FPI, it is
definitely a DTD, and this is an advantage for FPI's over URL, but not a
big one.  
 
> > www.w3.org corresponds to -//W3C.  
> 
> Not quite.  w3.org (the domain name, rather than the host name) is a
> better analogue.

Perhaps, but I'm drawing relationships between FPI's and URL to indicate
the perform more or less the same job.  They are different, and the
analogy are not perfect, but I believe they are adequate for the purposes
of identifying a document by name.
 
> > But the W3C doesn't actually doesn't own -//W3C like it owns
> > www.w3.org, and anyone can make a document with the FPI -//W3C.  
> 
> True.  
> 
> Have you seen K.4.6 "Internet domain names in public identifiers" of
> the WebSGML TC?  http://www.ornl.gov/sgml/wg8/document/1955.htm
> You could have something like this:
> 
>    +//IDN w3.org::www//DTD 
>        XHTML 1.0//EN//http:/TR/xhtml-basic/xhtml-basic10.dtd
 
Wow, I think I may have heard of this in passing, but forgotten.  This
seems really good, maybe we should go with it?

> (which, amazingly enough, is best compared with a gopher string!)
> 
> > So really URL's a better in this respect.
> 
> No.  They're exactly the same.  The real problem is that, under the
> current rules, a URI can't be the minimum data following the PUBLIC
> keyword.  Of course, at root, this is just legalistic mumbo-jumbo, and
> the SYSTEM keyword is the official *kludge* to get around this
> "problem".  

Why is it a problem?  Why should PUBLIC identifiers be used over SYSTEM
identifiers. ... Um, can you define the semantics of PUBLIC and SYSTEM
identifiers?  Don't bother if it is too much trouble.

I don't see why you say they are the same in the regard.  W3C owns
*.w3.org, but doesn't own -//W3C. (Of your your suggestion above seems
better than either of the two I've been discussing.
 
> That is, there should never be a need for a PUBLIC *and* a SYSTEM
> identifier.  All you need in a document is a name - its internal
> syntax is irrelevant (except for *verification* purposes).  Internal
> syntax becomes important for an address, and all addresses should be
> in catalogs.  Make a reasoned argument that catalogs are *never*
> necessary, and you have a case that an address is as good as a name.

I agree there is no need for a PUBLIC and SYSTEM identifier. ...
Actually, I don't think I'll argue this point right now, I need to first
look up the semantics of PUBLIC xxx and SYSTEM xxx.  I believe URLs are
as good as FPIs _in this case_, but you may have a point that a public
identifier is needed and a system identifier is just wrong.  (I still
really like your FPI you gave here.)

I can't say that catalogs are never necessary, because I don't believe
it.  But in this case the URL as as good as (and probably better) than
the FPI I gave. ... Although your identifier seems better than the URL,
and I think you may have a point about PUBLIC vs SYSTEM, I need to look
into that.
  
> > So surprisingly, the URL is actually independent of machine name
> > (because of virtual machine names) and independent of protocol
> > (because of uniformity).
> 
> Please explain this "uniformity" bit.  What happens with ftp?

I admit this is the most confusing part of my argument.  Consider a DOS
like system.  This is not going to be a perfect analogy, but try to bear
with it.  Consider drives A: and C:.  Assume A: is a floppy disk and C: is
a hard drive.  Now the way that the OS access these drives (which are big
tables that maps keys (filenames) to data (files), are different.  But
this difference in protocol is transparent to the user, because weather
a drive is a floppy, or disk, or mapped network drive, doesn't change how
the table is access.  This is because each media is access (for the users
point of view) in exactly the same way.  This OS has made the access
uniform across media.  In the same way access via http: and ftp: are done
in exactly the same uniform ways in a URL. (a mapping from names to
data).

Now I admit the OS has a table that maps a drive letter to a protocol, so
C isn't always a hard disk, while http: is always uses the http protocol,
but my point was to illustrate what I mean by uniformity.  ftp and http
act somewhat like different drives on a computer.  Both give access to
two different tables.

-- 
Russell O'Connor                           roconnor@uwaterloo.ca
       <http://www.undergrad.math.uwaterloo.ca/~roconnor/>
``Paradoxically, a refusal to `put a monetary value on life' means that
life is often undervalued.'' -- Artificial Intelligence: A Modern Approach

Received on Friday, 18 February 2000 23:06:39 UTC