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
significant properties
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

David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________