Re: The furore over PUBLIC
At 9:01 PM +0700 3/31/97, James Clark wrote:
>At 00:47 30/03/97 +0000, Peter Flynn wrote:
>>Is it too much to propose that an identifier must be
>>either SYSTEM "url"
>>or PUBLIC "fpi" "url"
>This seems a reasonable compromise to me. No interoperability is lost,
>because there's always a URL that the system can use. It adds very little
>burden to implementers: they can just completely ignore the public
>identifier if they want.
I've certainly suggested this several times previously. I'd change the
wording of the description of PUBLIC (because I think PUBLIC has
other than resolution. More on that in my next post.
But in short, yes, this would be fine for the time being.
>The spec could just say something like:
>In addition to a system literal an external identifier may include a public
>identifier. A system may use the public identifier to try to generate an
>alternative URL. If a system is unable to do so, it must use the URL
>specified in the system literal.
>In a future version, when we have a resolution mechanism, we could maybe
>allow omission of the system identifier when there's a public identifier.
>The question is: do those who have been clamouring for public ids think this
>is better than no public ids at all?
I also don't object to suggesting or allowing the CATALOG approach. I think
it has the potential to become an embarassment, if it is a _required_
default behavior, and some mechanism makes the default behavior obsolete.
(I can see this happening multiple times in the multi-decade life of (at
least some) public indentifiers.
David Durand firstname.lastname@example.org \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________