Re: The furore over PUBLIC

Jon Bosak wrote:
> 
> [Peter Flynn:]
> 
> | Is it too much to propose that an identifier must be
> |
> | either          SYSTEM  "url"
> | or              PUBLIC "fpi" "url"
> |
> | and leave it to the much-vaunted "market forces" to resolve the issue?
> 
> It is if you feel, as I do, that in the case where a public identifier
> is given, it always takes precedence over a URL.  

Sure: it takes precedence when it can be resolved. When it cannot (e.g.
the software has no resolver), the URL takes precedence. What's the
problem?

> If it's the other
> way around (the URL takes precedence), and a URL is always required,
> then the public id is just decoration; a special variety of comment,
> if you will.

I have made that analogy before. I think it is a sign of good design
that we allow hooks for other people to extend our brilliance. It really
annoys me when people use real comments (<!-- -->) for "magic" commands.
It is, in my opinion, a violation of the implict SGML contract to label
things accurately that prevents us from using <FOREIGN> to markup things
we want italicized and <EMPH> to markup book titles -- though no DTD can
prevent it.

Processing instructions are another variety of "special comments." I do
not think that we should remove processing instructions, and I think
that we should add public identifiers. If we can also specify a default
(*not exclusive*) resolution mechanism, them I am even more in favour of
them.

As Joe English asks: who do these "special comments" hurt? 

Are implementors going to be reading the spec, notice those two
constructs and say: "If the processing of this <?PI thing and this
PUBLIC thing are not going to be well defined, then I'm taking my
marbles and going home." I highly doubt it. Rather, they will completely
ignore those parts of the standards until they are trying to figure out
particular problems, such as how to insert processor specifing
information, or implement persistent names. At that point a light will
come on in their head, they will notice the convenient "hooks" in the
specification, and they will implement something cool, like a URN
resolver or SOCAT catalogs.

Who loses by having comments with well-defined semantics ("application
specific code" and "persistent entity name") but no algorithmic
requirements? Why is the latter dangerous and ill-advised, but the
former routine and ordinary?

Once again, I think that it would be good to provide default processing
for PIDs, and am arguing that in other messages to Terry. But I think
that the argument that if we don't specify one XML will be laughed at is
bogus. Label it as "reserved for user agent experimentation" (as are
PIs) and let them ignore it if they aren't smart enough to see its power
then someone else will and will make some money off of it.

 Paul Prescod

Received on Monday, 31 March 1997 00:35:05 UTC