[Prev][Next][Index][Thread]

Re: the return of the Public Identifier Question (2 cc's deleted)



At 1:35 PM -0500 3/21/97, lee@sq.com wrote:
>    Note:  Peter and Eve and Terry and I know what happened when Panorama
>	   was changed, and how long it took to identify the problem!

As an intentional Windows non-user, I'm afraid I don't know. Care to share
it with us?

>The PUBLIC zealots can simply put PUBLIC IDs in their SYSTEM identifiers,
>and use CATALOG to map them to URLs.
>
>Note that
>    public:-//Percival//DTD XXX//JP
>is a perfectly valid URL, although there is no widespread resolution
>mechanism for it.  You can put that in any XML system identifier.
>Obviously a non-CATALOG XML system wouldn't be able to deal with it,
>so this would *require* all XML systems to handle CATALOG.

I made almost the same suggestion (allow URIs in system IDs instead of
URLs). This would make "urn:fpi:whatever" legitimate. But, for the
practical reason that having a might help simple implementations, adding
PUBLIC had some support. Since I expect that people should use PUBLIC and
SYSTEM as intended (exact functional equivalence) I don't think we need to
worry about the problem of "redundant" addresses resolving to different
values. That's a coding error like many others we can do nothing about --
and like most coding errors, most systems will "do something", with no
guarantee that the results are the same form system to system.

C programmers are not massively inconvenienced by having to avoid
statements like:

   c = c++ + c++;

they just avoid them because the results are unpredictable (by the standard).

so PUBLIC and SYSTEM can be easily worked with by using them correctly.

I also think that mapping system IDs via catalogs will totally trash URL
caching mechnaisms unless we make the catalog into a mandatory starting
point, since different documents might assume different catalogs, and thus
different mappings. Note that if we allow the DOCUMENT extension, mandatory
catalogs provide an elegant solution to DTD and Stylesheet attachment at
the cost of two HTTP requests. This would be unacceptable with http 1.0,
but since 1.1 uses persistent connections, it's not such a problem.

But we still have the problem that with only one ID, we have no fallback
mechanism. And if we use CATALOG to control all pulbic ID resolution, we
don't have an easy way to plug in a distributed name service, like the
NAPTR resolution for URNs that is in final ballot right now.

So, I think that it's not a completely boneheaded idea, but it still leaves
some significant unanswered questions.

Personally, I think any requirement that PUBLIC names be resolved in any
specific way is a problem. (Mandatory catalogs don't necessarily imply
this, as they would be a starting point, and local applications would be
free to ignore their prescribed mappings for PUBLIC IDs if a local copy or
local resolution service were preferable).

  -- 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                    \__________________________



References: