Re: FPI's in NOTATION declarations
At 11:40 PM 11/28/96 EST, firstname.lastname@example.org wrote:
>> The first is that the first namespace is formally organized and "bigger"
>> than DNS, IANA or Internic.
>What does bigger mean? I don't know how to interpret you here.
>The IETF is a recognised international standards body.
>The FPI namespace is no larger than dns --- they are both countably
>infinite, discounting practical length limitations...
>I am not sure why the size matters, though, as long as they're big enough.
Bigger in that URLs are *by definition* attached to a protocol.
"The Internet Assigned Numbers Authority (IANA) will maintain a
registry of URL schemes. Any submission of a new URL scheme must
include a definition of an algorithm for accessing of resources
within that scheme and the syntax for representing such a scheme."
FPIs can name things without reference to a particular resolution protocol
or method. So a "concept:" URL is not a URL...it is a URN, but does not
follow the URN syntax. It is a syntactic/semantic mixup.
>> The second is that FPIs can be "redirected" by the information consumer or
>> maintainer, where as URLs can only be redirected by the information
>I already pointed out that this isn't necessarily true.
I think that from a user interface, usability and "correctness" point of
view, having information consumers redirect URLs is wrong. Software can
redirect to a cache if it is confident that the cache is correct. Since a
URL must have a protocol (and usually a machine name) embedded within it,
resolving a URL without using that protocol/machine name is a mistake.
>Also, you are making an assumption about FPIs -- that the user can affect
>their resolution. There is nothing in ISO8879 that mandates that --
>quite the reverse, if anytyhing. I haven't checked the FPI standard,
>as I don't have access to a copy right now (sorry).
ISO8879 does not mandate it, but it allows it. According to Goldfarb'
annotation: "The system uses the other information available to it to
determine the actual storage location identifier." Whereas according to the
URL spec, http URLs must point to objects which can be resolved according to
the http specification.
>(2) A URL is a coordinate in cyberspace. To put it another way, a URL
> is indeed a resource's location, but that needn't be a resource
> that exists.
" This document specifies a Uniform Resource Locator (URL), the syntax
and semantics of formalized information for location and *access* of
resources via the Internet."
" This document describes the syntax and semantics for a compact string
representation for a resource *available* via the Internet."
"The HTTP URL scheme is used to designate Internet resources
*accessible* using HTTP (HyperText Transfer Protocol)."
>> Some people feel strongly that there should be a syntactic differentiation
>> between *names* and *locations*.
>Possibly. We will have that with URNs.
But we don't have to wait for URNs. Within closed systems, FPIs do that now.
XML FPIs may or may not be useful "across the Internet", but they are
immediately useful within systems like that which Jon uses.
>It is not meaningful to say that a concept has a URL. It is meaningful
>to say that you can use a URL to represent a concept, though.
A URN, yes. A URL, no.
>I was referring to URNs, not the HREF attribute of an HTML <A> element.
>You are going to have a hard time dereferencing your TeX Book example
>FPI too, if you "click on it".
But you *wouldn't* click on it because it is obviously a *name*. But
software quite rightly usually has a direct link from URLs to protocol
handlers (perhaps at the OS level). I can imagine clicking on a "concept:"
link and having a browser say: "concept:" protocol not installed.
>> Anyhow, a major benefit of having URLs *and* FPIs is redundancy. I think
>> that they should usually be used together.
>We don't need redundant syntax. We need a minimal language that people
How hard is it to read the word PUBLIC, skip the following string (the
public identifier) and use the string after that (the URL)?
>> > client-side indirection
>> Isn't that what SGML Open is for?
>You mean the CATALOG TR, I assume, rather than the organisation?
No, I mean the organisation. Don't they exist to help SGML vendors
interoperate? I don't think that there is anything wrong with SGML vendors
*not* interoperating in areas where there are no standards. I just wish SGML
Open could do more.
>> The problem FPIs partially solve
>> is *hard*. FPIs provide a partial solution that URLs do not.
>No. FPIs plus the SGML OPEN catalog plus URLs provide a partial solution.
FPIs provide a partial solution within an organization or software system,
as they always have. They were useful before SGML OPEN catalogs (didn't YOU
use them?). SGML OPEN standardizes a resolution scheme, to make them a
little more useful by standardizing a resolution system. URN resolvers will
make them a lot more useful, by standardizing a global resolution protocol.
URLs are, in my opinion, unrelated, except as a useful part of a resolution
protocol at some point in the future.
FPIs allow you to name things, so that if you happen to have a resolution
system (as every SGML user in the world *does*) then you can take advantage
of it. If you don't, you can use the URL.
>FPIs by themselves are nothing but structured strings, just like URLs,
>URNs, telephone numbers and those knotted Mayan things :-)
FPIs are like URNs and telephone numbers, but not URLs or people's
addressess. I'm not knowlegable about Mayan things, so I'd better not
express an opinion.
>> As I stated before, I think that this is attempting to make URLs into
>> something they are not. I don't really feel comfortable having clients
>> redirect URL accesses. With a separate syntax it is clear from the document
>> that a redirection is possible, if your tool supports it.
>But then every XML program needs to support the SGML OPEN catalog,
>and we have to work out how to associate an SGML OPEN catalog with
>every XML file, and how to do that in the presence of CGI, and how
>to store multuple XML document sets in the same directory without
>CATALOG conflict, and document it all, and still be under 20pp.
I am NOT proposing that we should specify a resolution protocol for FPIs
anymore than you are proposing a resolution protocol for "concept:" URNs. I
AM proposing that people should be able to name their entities and refer to
them by name within systems that support entity names (such as all existing
SGML systems, URN prototypes, etc.). When you deliver your document over the
Internet, though, it darn well better have *URLs* in it, if you want
Netscape and IE to be able to do useful things with it. But within your
corporation, or within a larger community, like TEI, you can name things and
allow "smart" consumer software to resolve the names, where available.